单元测试成为TDD的集成测试

Question

假设我正在编写一个使用测试驱动开发的应用程序。 我找到的所有样本都是非常小的例子，试图解释如何在TDD中编写测试。

当您在TDD中编写测试时，您编写了一小段代码，其目的是测试单个代码，单个方法，以及单元测试。

一段时间后，收到客户端的要求，您需要更改原始代码，以允许它接受更多的参数，并将方法分成多层的多种方法。

让我们说在发生故障时添加日志记录。那么我需要测试什么，单独记录组件，或者与原始方法链接在一起？

这意味着原来的单元测试实际上正在成为集成测试，因为我现在正在测试多个组件。

这是应该避免的，或者如果需要，如何解决这些问题？

亲切的问候

Answer 1

除了其他答案之外，您还可以查看书籍extended TDD cycle中定义的Growing Object-Oriented Software Guided by Tests。他们正在使用验收测试来驱动写单元测试的内循环;但是，根据具体情况，我发现你也可以使用集成测试来做到这一点。

所以没必要避免它们。根据我的经验，重要的是粒度和测试数量（更少的集成，更多的单元测试）。

Answer 2

现实世界中的TDD实际上使用了单元测试和集成测试。单元测试在教程中可以看到，因为它更容易理解简单的示例，但实际的应用程序需要一些集成测试。您编写的第一个测试通常是集成测试（参见bdd）。

然而，集成测试很慢且难以维护（它们触及系统的更多部分而不是单元测试，所以它们更频繁地更改），因此只需要根据需要进行尽可能多的集成测试并执行尽可能多的测试单位测试是合理的。

当对类的要求导致它变大并将类重构为较小的类时，其单元测试现在是集成测试。通过为新类编写重点单元测试并删除原始类的大多数旧测试来解决此问题。将一个或几个旧测试作为集成测试留下可能是适当的。重写一些旧的测试以使用测试双精度（存根，模拟等）来处理现在的其他类的实例也可能是合适的。巧合的是，我最近写了an answer about the mechanics of rewriting tests when you refactor a class out of another class。

Answer 3

无论TDD与否，单元测试的想法是隔离应用程序的一个单元并单独验证其代码流。单元通常是一个类，您将看到方法的每个代码分支至少一个单元测试。例如。如果classA.methodA（）有3个分支，那么你将有3个以上的单元测试。

真正的单元测试将模拟/存根的依赖项注入组件，调用要测试的方法并验证其行为和/或对象状态。原则上，单元测试应该鼓励您在松散耦合，关注点分离等方面改进源代码的设计。（SOLID原则）。

此外，代码覆盖率可以很好地衡量单元测试的质量，但建议不要追求100％。此外，为每个应用层编写单元测试都是过度的;您希望定位包含业务逻辑的层，以实现良好的投资回报。最后，不要在没有持续集成管道的情况下编写单元测试，因为它们很快就会变得陈旧。

相反，当您开始将两个或更多单元验证为一个测试时，它将成为集成测试，因为您的测试结果会受到每个单元成功或失败的影响。这些往往需要更多的努力来设置环境，由于外部依赖性而可能是片状的，并且可能基于事务量而变慢。这些肯定是有用的，你应该根据你的预算约束来实现代码覆盖。集成测试也应该是CI / CD管道的一部分，但可以比单元测试更少运行。

希望这有帮助。

Answer 4

单元测试和集成测试之间没有真正的根本区别。

您的某个类的低级（单元）测试可能还会运行并依赖运行时环境或应用程序框架提供的类。因此，您的单元测试也可以视为代码与运行时环境代码组合的集成测试。

它们之间没有根本区别，没有理由担心是否曾经标记过某些东西＆＃34;单元测试＆＃34;现在标有＆＃34;集成测试＆＃34;。