如何理解TDD的三条“童子军规”？

在美国童子军中，流传一条这样的军规：让营地比你来时更干净。Bob大叔在他的《代码整洁之道》中也引用这个词，提倡持续改进 – 作为一个专业高素养的程序员，要尽全力让项目代码随着时间流逝而越变越好。那么借用这个说法，在TDD中，我们也提倡三条童子军规：

• 没有失败的测试之前不要写任何功能代码
• 一次只写一个刚好失败的测试，作为新加功能的描述
• 不写任何多余的产品代码，让它刚好能让失败的测试通过就好

如果违反了这几条童子军规，会怎么样呢？

• 违反第一条，如果先编写了产品代码，那这段代码实现了什么业务需求呢？你又怎么确保它真的实现了呢？手工测试，太费时间。后补测试，交付压力这么大，还是先写新功能吧。
• 违反第二条，如果写了多个测试，测试长时间没法通过，会增加开发者的心里压力。实际上，伴随着知识的积累，业务细节的深入，Task会发生变更，测试会随之修改，那之前写的测试就成了累赘。
• 违反第三条，产品代码实现了超出当前测试的功能，这部分代码就没有测试的保护，又回到第一条了。另外，多些的代码可能是不存在的需求，增加了没必要的复杂性。

据我观察，别说TDD的初学者，就是有一定经验的TDDer，也很难时刻做到一次只编写刚好让测试通过的功能代码。我还见过有些人一上来写上10来个测试用例。那么在实践练习的过程中，在开始守（守、破、离）的阶段，可以时刻用这三条军规提醒自己。