100 天的 TDD 实践

直到最近，我还在Humana DEC的一个极限编程团队工作。我们每天都实践测试驱动开发（TDD）。100 天后，我想指出 TDD的理论和实践之间的一些差异。

所以，关于TDD的三大定律，我有几点需要说明：

1. 你不需要测试所有内容。
2. 你可以一次编写多个失败案例
3. 在纳米周期中，你不需要实践TDD。
4. 设计决策应推迟到蓝色阶段。
5. 你也应该重构测试。

在你砸屏幕之前，请允许我解释一下。

你不需要测试所有内容。

理论上，根据TDD第一定律：

在编写出一个会失败的测试之前，你不能编写任何代码。

实际上，我很少为内容、设计、配置等编写测试。我会为任何包含逻辑的代码编写测试。

你可以一次编写多个失败案例

理论上，根据TDD第二定律：

你编写的测试用例不能超过导致测试失败的程度。

实际上，我经常一次编写几个失败的测试用例。不过，这些失败通常都在同一测试中，并且始终处于同一级别。也就是说，先编写几个单元测试失败的测试用例，或者几个集成测试失败的测试用例。然后，我会逐一让它们通过。

在纳米周期中，你不需要实践TDD。

理论上，根据TDD第三定律：

你编写的代码量不能超过通过当前失败测试所需的代码量。

在实践中，当使用新的代码库或新技术时，我会遵循 TDD 法则第 2 和第 3 条。一旦熟悉了，我会在一个测试周期内完成失败的测试和通过测试的代码编写。我认为没有必要以最低速度重复红绿测试循环^[1]。

设计决策应推迟到蓝色阶段。

理论上，正如 TDD 第三定律所指出的，绿色阶段是指编写最少的代码使测试通过。

实际上，很多人会在代码测试通过（绿色阶段）或更早的时候进行重构。这太早了。为了避免在绿色阶段进行重构，我几乎在所有事情上都提倡“你不需要它”（YAGNI）原则。将设计决策推迟到蓝色阶段。到那时，你对代码和测试会有更深入的了解，从而更好地指导你的重构。

你也应该重构测试。

理论上，所有代码都应该重构。

在实践中，测试很少被重构。测试也是代码，应该在蓝盘阶段进行重构。此外，在实践测试驱动开发（TDD）时，测试本身也扮演着文档的角色。因此，确保测试代码清晰易懂至关重要，甚至更为重要。

[1]在撰写本文时，我发现了一篇鲍勃大叔的文章，他在文中讨论了不同的测试驱动开发（TDD）周期。上述大部分理论都基于纳周期。而我所描述的实践主要结合了分钟周期及之后的周期。

还想了解更多？请在 Twitter 上关注@gonedark，每周获取编程技巧、实用转发和其他精彩内容。