5.1 此事已有定论

• 此事已有定论！
• 争论已经结束。
• GOTO是有害的。
• TDD确实可行。

TDD的确切实可行，并且，每个开发人员都要适应和掌握TDD。

5.2 TDD的三项法则

1. 在编好失败单元测试之前，不要编写任何产品代码
2. 只要有一个单元测试失败了，就不要再写测试代码：无法通过编译也是一种失败情况
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写

5.3 TDD的优势

5.3.1 确定性

如果将TDD作为一项行业纪律，那么每天要写上几十个测试，每周要写上成百上千个测试，每年要写上成千上万个测试。任何时刻，代码有任何修改，都必须运行手头有的全部测试。

5.3.2 缺陷注入率

有不少报告和研究称TDD能显著降低缺陷。

5.3.3 勇气

拥有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。当看见糟糕的代码时，就可以放手整理。代码会变得具有可塑性，你就可以放心打磨出简单而满意的结果。

5.3.4 文档

单元测试即是文档。它们描述了系统设计的最底层设计细节。

5.3.5 设计

测试代码的一个问题是必须隔离出待测试的代码。

换言之，测试先行的需要，会迫使你去考虑什么是好的设计。

遵循三项法则并且测试先行，便能够产生一种驱动力，促使你做出松耦合的设计。

5.3.6 专业人士的选择

TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。

5.4 TDD的局限

遵循这三项法则并不能担保一定会带来上述好处。即使做到了测试先行，仍有可能写出糟糕的代码。

另外，在某些场合按照这三项法则去做会显得不切实际或不合适。