如果我已经有集成测试，是否需要单元测试？

如果我已经对我的程序进行了集成测试，并且都通过了测试，那么我有很好的感觉，它可以工作。那么编写/添加单元测试的原因是什么？由于无论如何我都必须编写集成测试，所以我只想为集成测试未涵盖的部分编写单元测试。

我知道单元测试优于集成测试的好处是

• 体积小，因此运行速度快（但是，通过集成测试已经测试了添加新单元以测试某件东西，这意味着我的总体测试服变得越来越大，并且运行时间更长）
• 由于只测试一件事，因此更容易找到错误（但是，当我的集成测试失败时，我可以开始编写单元测试来验证每个单独的部分）
• 查找集成测试中可能未捕获的错误。例如掩盖/抵消错误。（但是，如果我的集成测试通过了所有测试，这意味着即使存在一些隐藏的错误，我的程序也可以运行。因此，找到/修复这些错误并不是真正的高优先级，除非它们开始破坏未来的集成测试或引起性能问题）

而且，我们总是希望编写更少的代码，但是编写单元测试需要更多的代码（主要是安装模拟对象）。我的一些单元测试和集成测试之间的区别在于，在单元测试中，我使用模拟对象，而在集成测试中，我使用真实对象。其中有很多重复项，即使在测试中，我也不喜欢重复的代码，因为这会增加更改代码行为的开销（重构工具无法始终保持所有工作）。

您已经提出了支持和反对单元测试的良好论据。因此，您必须问自己：“ 我是否会在积极的论点中看到价值大于在消极的论点中付出的代价？ ” 我当然会这样做：

• 小型快速是单元测试的一个不错的方面，尽管绝不是最重要的。
• 轻松查找错误非常有价值。许多有关专业软件开发的研究表明，错误的成本随着其年龄的增长和在软件交付渠道中的下降而急剧上升。
• 寻找被掩盖的错误很有价值。当您知道某个特定组件的所有行为均已验证时，可以放心使用以前从未使用过的方式使用它。如果唯一的验证是通过集成测试，则您仅知道其当前使用行为正确。
• 在现实情况下，模拟是昂贵的，而维护模拟则是双重的。实际上，当模拟“有趣的”对象或接口时，您甚至可能需要测试来验证您的模拟对象正确地对真实对象进行建模！

在我的书中，利弊大于利弊。

我认为重新实现现有的集成测试用例作为单元测试没有太大的价值。

对于非tdd遗留应用程序，集成测试通常更容易编写，因为通常要测试的功能紧密耦合，因此孤立的测试单元（=单元测试）可能难以实现/昂贵/不可能。

> Then what are the reasons to write/add unit tests?

我认为，如果您在实际代码之前编写单元测试，那么测试驱动的开发最有效。这样，满足测试要求的代码就被清晰地分隔开了，并带有最少的易于测试的外部引用。

如果代码已经存在而没有单元测试，那么以后编写单元测试通常会花费很多额外的工作，因为代码不是为便于测试而编写的。

如果您执行TDD，则自动测试代码很容易。

集成测试应仅验证几个组件是否按预期工作。各个组件的逻辑是否准确，应通过单元测试进行验证。
大多数方法都有几种可能的执行路径。考虑一下if-then-else的输入变量，这些变量具有意外的值或只是错误的值，等等。通常，开发人员倾向于只考虑快乐的路径：不会出错的正常路径。但就其他路径而言，您有两个选择：您可以让最终用户通过他们在UI中执行的操作来探索这些路径，并希望他们不会使您的应用程序崩溃，或者可以编写断言的单元测试。其他路径的行为，并在必要时采取措施。

您在问题中指出的某些原因确实很重要，就其本身而言，很可能会支持单元测试，但YMMV却很有用。例如，您多久运行一次集成测试套件？我在集成测试中的经验是，它们迟早会变得如此缓慢，以至于您每次进行更改时都不会运行它们，并且插入和检测错误之间的时间会增加。

另外，您可能会犯的一个大错误就是相信

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

并不重要。您是否希望您的用户为您找到错误？在我看来，信任从集成测试中获得的承保范围很危险，您可以很容易地获得很高的承保范围，但实际上您的测试很少。

我认为针对集成测试的规范参考是JBrains的帖子：

http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

如果您还没有阅读它们的话。

最终，IMO从设计的单元测试中获得的反馈是非常宝贵的。通过直觉判断设计并依靠集成测试也可能是一个错误。

如果您希望修改或重构代码，则必须进行单元测试。单元测试不仅用于演示编写代码时的错误，而且还用于显示在编写更多代码时何时出现新的错误。

是的，最好先编写集成和单元测试，但是即使稍后再编写它们，也具有很多价值。