事后单元测试的优缺点答案

【问题标题】：Pro's and Con's of unit testing after the fact事后单元测试的优缺点
【发布时间】：2010-03-22 16:49:19
【问题描述】：

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

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

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

你说什么。

【问题讨论】：

@closers 哦，别说了，伙计们。这是一个很好的问题。
更新。我花了 5 个月的时间来测试它。即使每个组件都经过独立测试，它也被严重破坏。一些非常讨厌的虫子和一小撮黑森虫。一只特别的黑森虫力量强大，花了 4 周时间才找到。 VS2k10 和国际象棋在这里有很大帮助，综合日志文件也是如此。

标签： unit-testing testing

【解决方案1】：

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

回归管理
更好地理解代码。对其进行测试将揭示您没有预料到的情况，并有助于定义代码的行为
当您努力测试定义不明确的方法时，它会指出代码中的设计缺陷。

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

【讨论】：

+1 以便更好地理解代码。我目前正在根据为常见使用场景编写单元测试时发现的问题重构系统。
我真的不会说没有缺点。您很容易花费大量时间尝试（并失败）为未考虑可测试性而设计的系统编写测试，或者为易于测试但稳定且基本上没有错误的部分编写测试，最终得到的结果很少价值和/或很难维护的测试套件。
在没有经过单元测试的情况下，很少有重要的代码块是真正没有错误且稳定的。有所有你从未触发过的罕见条件。
对于“正常”测试，测试人员不知道有哪些单元，也不知道每个单元中存在哪些稀有条件，即使知道，也很难知道如何通过整个集成系统触发它们。例如，您可以获得仅在罕见的与线程相关的计时问题时发生的条件，您根本无法在正在运行的系统上选择触发它们。如果你同时写单元测试和单元，你可以看到所有的决策点并进行测试。如果您真的想认真一点，甚至还有一些工具可以检查您的测试覆盖率。
+1：没有缺点。您可以花钱尝试（和失败）编写测试来表明您有质量问题。这不是“沉没”——这是“学习”。现在了解当您有机会修复它时需要修复什么。

【解决方案2】：

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

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

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

回归测试将变得更简单
知识较少的其他开发人员无法破坏您想要的行为
测试是一种自我记录的形式
可以减少未来修改的时间（不再需要手动测试？减少错误？）

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

【讨论】：

代码通过单元测试并通过后仍然可以被破坏 - 但我当然同意基本观点。
你也可能有坏的和损坏的单元测试代码。单元测试只是意味着代码经过测试，而不是它没有损坏或质量低下。不要误会我的意思，我喜欢单元测试，但它就是这样。

【解决方案3】：

根据“手动测试”出现的错误数量，您可以简单地进行测试驱动的错误修复，根据我的经验，这比通过编写“post- mortem”单元测试。

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

【讨论】：

我同意。如果没有 TDD，我永远不会再开发这种规模的产品。
这个主观答案是如何获得批准的？我认为 SO 与意见无关。

【解决方案4】：

以下是我想到的一些：

亲：

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

缺点：

编写测试需要大量时间，新功能可能会延迟一段时间才能生成所有测试。
可能引入了测试会发现的错误，这些错误可能会导致此时间比最初计划的要长。

主要的一点是添加单元测试允许重构和对应用程序进行更多改进。

【讨论】：

【解决方案5】：

我认为“事后”测试的最大弊端之一是您可能会更难进行测试。 如果您在没有测试的情况下编写代码，您通常不会考虑可测试性并最终编写出难以测试的代码。

但是，在您花费这些额外的时间编写测试并更改代码以获得更好的可测试性之后，您将更有信心进行更改，一旦您不需要很多时间调试并检查是否一切正常。

最后，您可能会发现以前没有发现的新错误，并花一些时间修复它。但是，嘿，这就是测试的目的 =)

【讨论】：

【解决方案6】：

专业事后单元测试：

获取您可以信任的文档。
提高对代码的理解。
推动重构和改进代码本身。
修复隐藏在代码中的错误。

Con 事后单元测试：

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

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

【讨论】：

这是生产代码，不是原型代码，但我理解你的意思。
这是真实的生活观

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

话虽如此，我发现事后进行测试需要做更多的工作（如果您想获得相同级别的测试）。它仍然很有价值，仍然值得。

就个人而言，当尝试在有限的时间内解决问题时，我会尽量集中测试工作。每当您修复错误时，请添加测试以帮助将来防止它。每当您要重构时，请尝试进行足够的测试以确保您不会破坏某些东西。

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

【讨论】：

【解决方案9】：

单元测试仍然很有用。查看 http://en.wikipedia.org/wiki/Unit_testing 以获取完整列表和好处说明。

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

除了您的时间之外，添加单元测试确实没有任何成本。请注意，尽管您花在添加单元测试上的时间会减少您在其他开发领域所需的时间，但至少会减少相同的时间，而且很可能会更多。

【讨论】：

【解决方案10】：

单元测试并不能证明系统有效。它证明了每个单元作为一个独立的单元工作。并不能证明集成系统会起作用

“事后”单元测试对两件事很有用 - 发现迄今为止您遗漏的错误并且使用任何其他类型的测试都找不到（尤其是对于罕见的情况 - 有大量的罕见情况可以发生在任何现实世界系统的特定单元中），并在维护期间作为回归测试。

这些都不会对您的情况有太大帮助 - 您需要以任何一种方式进行其他形式的测试。如果您没有时间做您需要做的事情，那么承担更多的工作可能无济于事。

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

我赞同那些说单元测试应该作为编程过程的一部分来编写的人——这是程序员的职责之一。通常，以这种方式编写代码更快，因为您需要跟踪的错误越来越少，而且当您仍然熟悉代码时，您往往会发现它们有错误。

【讨论】：

【解决方案11】：

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

【讨论】：

【解决方案12】：

这是这些困难的价值判断类型的问题之一。

我基本同意 Epaga 的观点，即在修复错误时编写新测试（可能加入一些额外的测试）是一种好方法。

我会再添加两个 cmets：

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

【讨论】：