有不同类型的测试:单元测试、集成测试、功能测试和验收测试。因此，如果我正在进行适当的测试驱动开发，那么我应该在什么时候编写每种类型的测试?
我认为在典型的TDD中，单元测试是在编写代码之前的那种测试。我看到的典型工作流程是:
- 写失败unit test
- 运行测试以验证失败 编写最简单的传递函数/方法
- 运行测试以验证它通过 <
- 重构代码/gh>
如此如此……集成测试、功能测试和验收测试从何而来?你是在代码之后写它们吗?还是在一开始就将它们与单元测试一起编写?
另外，作为一个附加问题，我经常听到"100%代码覆盖率"的想法。很容易看出这将如何应用于单元测试——只需对每个方法进行一个测试。但是您是否应该为每种类型的测试提供100%的代码覆盖率?例如，单元测试是否应该覆盖100%的代码，功能测试是否应该覆盖100%的代码(尽管从更广泛的角度来看)?
虽然它倾向于更自然地适合较低级别的测试，但TDD实际上是一种可以应用于任何(或所有)级别的思维方式。您可以编写一个失败的验收测试，然后编写相应的失败的集成测试，将它们分解为失败的单元测试，然后在您使链中的每个测试都通过时，以"绿色"的方式返回到原始的验收测试。
一篇说明这一点的文章:ATDD From the Trenches
关于代码覆盖率，根据我的经验，您可以从单元测试和/或集成测试中获得大部分代码覆盖率，这取决于您在测试风格中喜欢的隔离程度。无论如何，我认为它们是互补的，您不应该在每个测试类别中寻找100%的覆盖率。另一方面，更高级的(系统、端到端、验收……)测试通常会发现配置/环境问题，这通常不会对代码覆盖率产生影响。
我通常首先编写一个外部测试，它将驱动特性的开发。这种方法是伦敦TDD学院的一部分。
正如Jason Gorman在上面的文章中所强调的那样，伦敦学派的权威文本是Steve Freeman和Nat Pryce的《成长中的面向对象软件指南》。