我什么时候应该在 TDD 中编写不同类型的测试？

Question

有不同类型的测试：单元、集成、功能和验收。那么，如果我在进行适当的测试驱动开发，我什么时候编写每种测试？

我认为在典型的 TDD 中，单元测试是在编写代码之前进行的那种测试。我看到的典型工作流程是：

1. 写入失败的单元测试
2. 运行测试以验证它是否失败
3. 编写最简单的传递函数/方法
4. 运行测试以验证它是否通过
5. 重构代码

太棒了...集成、功能和验收测试从何而来？你是在代码之后写的吗？还是一开始就和单元测试一起写？

另外，作为一个附加问题，我经常听到这种“100% 代码覆盖率”的想法。很容易看出这将如何应用于单元测试——只需对每种方法进行一次测试。但是，您是否应该针对每种测试实现 100% 的代码覆盖率？例如，单元测试是否应该覆盖我的代码的 100%，而功能测试是否应该覆盖我的代码的 100%（尽管从更广泛的角度来看）？

Answer 1

虽然它更自然地适合较低级别的测试，但 TDD 实际上是一种可以应用于任何（或所有）级别的思维方式。您可以编写一个失败的验收测试，然后编写相应的失败的集成测试，将它们分解为失败的单元测试，然后在链中的每个测试都通过时“绿色化”回到最初的验收测试。

一篇文章说明了这一点：ATDD From the Trenches

关于代码覆盖率，根据我的经验，您可以从单元测试和/或集成测试中获得大部分代码覆盖率，具体取决于您在测试风格中喜欢的隔离程度。无论如何，我认为它们是互补的，您不应该在 每个 测试类别中寻找 100% 的覆盖率。另一方面，更高级别（系统、端到端、验收......）测试通常会解决配置/环境问题，这通常不会对代码覆盖率产生影响。

Answer 2

我通常首先编写一个外部测试来推动功能的开发。这种方法是 TDD 的London School 的一部分。

正如 Jason Gorman 在上述文章中强调的那样，伦敦学校的权威文本是 Growing Object Oriented Software Guided By Tests，作者是 Steve Freeman 和 Nat Pryce。