事后的单元测试的优点和缺点

Question

我有一个大约27k线的大型复杂应用程序。它本质上是一个规则驱动多线程处理引擎，没有给予太多它已经部分测试，因为它已经构建，某些组件。

我有问题，在事实之后进行单元测试的专业人员是什么，可以说，在实施之后。很明显，传统的测试需要2-3个月的时间来测试每个方面，而这一切都需要工作，而且这个时间真的不可用。

我过去做过一些单元测试，但一般都是桌面自动化或LOB应用程序，这些都非常简单。该应用程序本身是高度组件化的内部，真正的界面驱动。我还没决定使用什么特定的框架。任何意见，将不胜感激。

你说什么

Answer 1

我认为单元测试现有代码有几个优点

• 回归管理
• 更好地理解代码。测试将显示您未预料到的案例，并有助于定义代码的行为
• 当你试图测试定义不明确的方法时，它会指出代码中的设计缺陷。

但我认为考虑单元测试代码的缺点会更有趣。 AFAIK，没有缺点。除了最短的时间周期外，所有花在添加测试上的时间都会为自己付出代价。

Answer 2

单元测试代码有很多原因。事后我提倡单元测试的主要原因很简单。 您的代码已损坏，您还不知道。

软件中有一条非常简单的规则。如果没有测试代码，它就会被破坏。这可能一开始并不是很明显，但是当您开始测试时，将发现错误。由你决定你发现这些错误的程度。

除此之外，单元测试还有其他几个重要的好处，

• 回归测试将变得更简单
• 其他知识渊博的开发人员无法打破您期望的行为
• 测试是一种自我文档形式
• 可以减少未来修改的时间（不再需要手动测试？，减少错误？）

列表可以继续。唯一真正的缺点是编写这些测试所需的时间。我相信这个缺点总是会被你调试的时间所抵消 单元测试时你可能遇到的问题！

Answer 3

根据“手动测试”出现的错误数量，您可以简单地执行测试驱动的错误修复，根据我的经验，这比通过编写“post-post”简单地提高代码覆盖率更有效死亡“单元测试。

（这并不是说之后写单元测试是一个坏主意，只是 TDD几乎总是一个更好的主意。）

Answer 4

以下是我的一些想法：

亲：

• 随着设计随着时间的推移而不必测试已被删除的方法，节省了时间。剩下的就是真正需要测试的东西。
• 通过添加测试，这样就有机会审查应用程序中的所有方面，并确定在工作原型准备就绪后可以添加的其他优化。

缺点：

• 为了完成测试而花费大量时间投入，新功能可能会延迟一段时间以生成所有测试。
• 可能已经引入了一些错误，测试会发现这可能导致这个错误比最初计划的更长。

重点是添加单元测试允许重构并在应用程序上进行更多润色。

Answer 5

我认为“事后”最大的测试之一就是你可能会有更难的测试时间。 如果您编写没有测试的代码，通常不会考虑可测试性，最终编写难以测试的代码。

但是，在您花费额外时间编写测试并更改代码以获得更好的可测试性之后，一旦您不需要花费大量时间，就会对更改更有信心调试并检查一切是否正常。

最后，您可能会发现之前未捕获的新错误，并花些时间修复它。但是，嘿，这就是测试的目的=）

Answer 6

Pro 事后单元测试：

• 获取您可以信赖的文档。
• 提高对代码的理解。
• 推动重构并改进代码本身。
• 修复潜伏在代码中的错误。

Con 事后单元测试：

• 浪费时间修复您可以忍受的错误。 （如果你写了27KLOC，我们希望它能做点什么吧？）
• 花时间理解和重构您不需要理解的代码。
• 失去可以进入下一个项目的时间。

问题这个代码资产对您的组织的长期影响有多重要？这个问题的答案决定了您应该投入多少资金。我有很多（成功的）竞争对手，其代码的主要目的是获取数字来评估一些新的技术或想法。一旦他们有了数字，代码就没什么边际价值了。他们（正确地）仔细测试以确保数字有意义。在那之后，如果有五十个开放的错误不影响数字，他们就不在乎了。他们为什么要这样？该代码已达到其目的。

Answer 7

如果您正在进行任何重构，那么这些测试将帮助您检测出现在流程中的任何错误。

Answer 8

“事后”的单元测试仍然很有价值，并且在开发过程中提供了大部分相同的单元测试优势。

话虽这么说，我发现事后测试更多的工作（如果你想获得相同级别的测试）。它仍然很有价值，但仍然值得。

就个人而言，在尝试用有限的时间处理某些事情时，我会尽可能地集中我的测试工作。每当您修复错误时，添加测试以帮助防止它在将来发生。无论何时你要进行重构，都要尝试进行足够的测试，以确信你不会破坏某些东西。

添加单元测试的唯一方法是它需要一些开发时间。就个人而言，我发现用于测试的开发时间远远超过维护所节省的时间，但这是您需要自己确定的。

Answer 9

单元测试仍然非常有用。查看http://en.wikipedia.org/wiki/Unit_testing以获取完整列表并了解其优势。

您将获得的主要好处是文档，使更改更容易，并简化了未来的集成。

除了您的时间之外，添加单元测试确实没有任何成本。但要意识到，添加单元测试所花费的时间将减少您在其他开发领域花费的时间，至少相同数量，甚至更多。

Answer 10

单元测试不能证明系统有效。它证明了每个单元都是一个独立的单元。它并不能证明集成系统能够正常工作

单元测试“事后”对于两件事情是有用的 - 找到你到目前为止错过的错误，并且不会发现使用任何其他类型的测试（特别是对于罕见的情况 - 有大量罕见的条件可以发生在任何现实世界系统的特定单元中），以及维护期间的回归测试。

这些都不会对您的情况有所帮助 - 您需要以任何方式进行其他形式的测试。如果你没有时间去做你需要做的事情，那么接受更多工作也不大可能有所帮助。

也就是说，如果没有单元测试，我保证当客户开始使用代码时你会有令人讨厌的惊喜。这是所有罕见的条件 - 其中有很多条件，其中一些必然会很快发生。黑盒测试者倾向于进入习惯模式，这意味着他们只测试这么多罕见的情况 - 他们无法知道特定单位中的罕见情况以及如何触发它们。更多用户意味着使用模式的更多变化。

我和那些认为单元测试应该作为编程过程的一部分编写的人 - 程序员的职责之一。通常情况下，代码会以这种方式更快地编写 ，因为随着时间的推移，您可以获得越来越少的复杂错误，当您仍熟悉代码时，您往往会发现它们那有虫子。

Answer 11

如果开发“完成”，我会说单元测试没有太多意义。

Answer 12

这是这些难以评估的问题类型之一。

我主要赞同Epaga，在你修复错误时编写新的测试（可能还有一些额外的测试）是一个很好的方法。

我想补充两点评论：

• 在进行大量更改之前对单元进行后退黑盒测试可能是一个好主意
• 一致性测试不是单元测试，但某些类型的程序可以轻松生成一致性测试。这可能是确保不破坏事物的一种方法。