你是否曾经整合过一个第三方库到你的项目中呢？你拿到一本厚厚的精致的帮助文档，在结尾处，有一沓薄薄的示例附录。你会选择哪个去阅读呢？当然是示例了！那就是单元测试啊！它们是这份文档中最有用的部分；它们是如何使用代码的鲜活的例子；它们是极其详细、完全没有歧义的设计文档，相当的正规甚至可以执行，而且不会与产品代码相脱离。
好处还不只这些。如果你曾有过增加单元测试到一个可以工作的系统中的经历，你会发现那一点儿都不好玩。你很可能会发现想跑通测试，你一定是要么去改变系统中的部分设计，要么就在测试上作假。这是因为你试图去测试的系统并不是基于可测试设计的。例如，你想要测试某个函数f。然而，f调用了另外一个从数据库中删除记录的函数。在你的测试中，你不希望这条记录被删掉，但却没有办法来阻止它。这样的系统就不是基于可测试设计的系统。
当你遵循TDD的三条规则的时候，你的所有代码天生就可测试！而且另一个能形容“可测试”的词汇就是“可解耦”。为了单独的测试一个模块，你就必须把它解耦。所以TDD强制你去解耦这些模块。确实，如果你遵循这三条规则的话，你会发现你可能比起从前来能做出更多的解藕。这就强制了你去创造更好的，低耦合的设计。
收获了所有的这些好处，这些愚蠢的小规则实际上好像就没那么愚蠢了吧。他们实际上很可能是一些基本而又深刻的原则。确实，在我接触TDD之前我曾做过将近30年的程序员，我不认为曾有过什么人教过我什么非常奏效但又基本的编程实践。毕竟三十年意味着很多的经验。但当我开始了使用TDD，我就被这项技术的有效性所震撼，也沉迷其中。我不会再考虑去敲一大堆代码然后平白指望它们能运行成功。对于那种先将一组模块打散，然后希望能够再将它们整合起来，并且让它们在能下个礼拜五前运行起来的做法，我也不再能忍受。在我写程序的时候，每一个决定都由这种让现在开始写的代码能在一分钟后再次执行这样的基本需求所驱使着。
译注：
1，TDD，测试驱动开发。
2，Kata，可理解为武功招式
文章来源于领测软件测试网 https://www.ltesting.net/
