TDD是否包括集成测试？

Question

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

谢谢！

Answer 1

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

摘录自大书的<< [面向对象的软件的增长，由测试指导演示了TDD中的这两个反馈循环：

<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLnN0YWNrLmltZ3VyLmNvbS9nNVhrSS5wbmcifQ==” alt =“ TDD”>

您的问题的答案是肯定的-TDD包括集成测试。这是不打破TDD黄金法则的唯一方法。

Answer 2

解决方案是大部分时间不使用真实的数据库

尽管如此，它仍然不能阻止您编写其他一些测试来验证您的生产代码是否可以与实际的数据库或相关的昂贵资源（如果需要的话）进行很好的结合：

如果模拟对象的行为不像真实对象怎么办？您可以通过对模拟对象进行一系列测试来减少这种策略也可以应用于可用的真实对象。

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

Answer 3

进行

Test Driven开发的主要原因之一（与编写测试

after编写代码相对）是helps direct low level design。在一定程度上讲，这很重要，它必须是单元测试而不是集成测试。

Answer 4

after编写代码相对）是helps direct low level design。在一定程度上讲，这很重要，它必须是单元测试而不是集成测试。