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

Question

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

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

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

Soooo ......集成，功能和验收测试在哪里进行？你是在代码之后写的吗？或者你是否在一开始就将它们与单元测试一起编写？

另外，作为一个额外的问题，我经常听到这个＆＃34; 100％代码覆盖率＆＃34;理念。很容易看出这将如何应用于单元测试 - 只需对每种方法进行一次测试。但是，您是否应该为每种测试提供100％的代码覆盖率？例如，单元测试应该覆盖我的代码的100％，功能测试覆盖100％的代码（尽管从更广泛的角度来看）？

Answer 1

虽然TDD倾向于更自然地适应较低级别的测试，但TDD实际上是一种可以应用于任何（或所有）级别的思维模式。您可以编写一个失败的验收测试，然后编写相应的失败集成测试，将它们分解为失败的单元测试，然后再进行“绿色调整”。当您在链条传递中进行每项测试时，您将回到原始验收测试。

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

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

Answer 2

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

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