TDD是否包含集成测试？

Question

我正在研究一些包含数据库访问的代码。测试驱动开发是否包括集成测试以及通常的单元测试？

谢谢！

Answer 1

TDD的黄金法则规定：永远不要在没有测试失败的情况下编写新功能。

如果您不遵循此规则，那么您正在部分执行TDD（例如，仅为应用程序中的多个类编写单元测试）。这比什么都好（至少你知道这些类做了什么，但你不能确定应用程序的其他部分是否正常工作，这些类可以与它们集成），但这并不能保证你的应用程序按预期工作。因此，您需要通过编写失败验收测试来启动每个功能，该测试指导您的应用程序设计并定义应用程序行为（外部循环）。虽然此测试失败，但您的应用程序未实现该功能。然后你应该为单独的单元编写单元测试，这些单元将涉及这个特性（内部循环）。外循环验证功能中涉及的所有类是否按预期一起工作。内部循环验证每个类是否按预期工作。

以下图书不断增长的面向对象软件，测试指导演示了TDD中的这两个反馈循环：

回答你的问题是 - TDD包括集成测试。这是不打破TDD黄金法则的唯一途径。

Answer 2

AFAIK，TDD最初没有区分单元测试和集成测试。在你需要建立的资源方面，集成测试通常要花费更多，这就是为什么即使在早期的TDD文献中，模拟也被认为是一种很好的做法。

来自Test-Driven Development By Example（“模拟对象”模式）：

  

解决方案不是在大多数时间使用真实数据库

但是，如果需要，它不应该阻止您编写一些其他测试来验证您的生产代码是否与真实数据库或昂贵的资源相匹配：

  

如果模拟对象的行为与真实对象不同，该怎么办？您可以   通过对模拟对象进行一组测试来减少此策略   也可以在真实对象可用时应用于它。

总而言之，我猜整个集成与单元测试的东西是与TDD正交的。换句话说：有一个小的红色/绿色/重构反馈循环，因为你的原子构建块不能确定你应该选择哪种整体应用程序开发工作流程或者哪些其他反馈循环应该包围它 - 它可以被接受为@lazyberezovsky解释，从内到外或从内向外，以集成为中心或以隔离为中心等，只要您对测试优先方法保持真实。

Answer 3

我会说'正常'的tdd周期，red - green - refactor，db访问应该被嘲笑。至于这个单元测试使用，测试部分应尽可能小。但是，必须对每个项目进行集成测试。

Answer 4

执行测试驱动开发的主要原因之一（与编写代码后编写测试相反）是helps direct low level design。在某种程度上这很重要，它必须是单元测试而不是集成测试。