什么是测试驱动开发

经过这几天的观察，我相当surprise地发现，很多同志还没有明白什么是“测试驱动开发”：开发之前写的测试是干什么用的——之所以说“surprise”，因为既有“惊讶”，也有“惊喜”。结合着最近做高校巡讲遇到的问题，我稍微做一些解释。

（前面的讨论：
http://forum.javaeye.com/viewtopic.php?t=19959
http://forum.javaeye.com/viewtopic.php?t=20035）

看“测试驱动开发”这个名字，首先应该明确：与它对应的是“文档驱动开发”。它是一种开发过程，这里的测试是一个设计问题，而不是QA问题。在没有TDD之前，“正统的”开发过程要求有设计文档：高层设计描述一个模块“做什么事”，详细设计描述一个模块“如何做这些事”。软件工程课讲得清楚，只有源代码的软件不能算软件，因为它不可理解、不可维护；源代码加上文档，才算是程序员完整地交付了自己的工作。要做任何一件事之前，你必须首先清楚地知道自己要做什么（以及不要做什么），否则那就是crack，不是在从事职业的软件开发。

但这种文档有几个致命的缺陷。第一，自然语言的描述容易产生歧义；第二，不能自动化地验证；第三，不能保证文档与程序同步。测试驱动开发正是为了解决这些问题而产生的。在编写一段代码之前你所写的测试，不是为了确保这段代码不出错，而是为了描述你想要做的事情。当你拥有这个测试之后，持续集成会始终确保你的代码恰好是做了你想要做的事情。测试驱动开发是一种设计方法，它清晰无二义地描述你的设计，并保证设计与实现一致。

所以几个典型的问题就可以很清楚地找到答案。单元测试要不要是白盒的？要。因为你是在描述如何实现这个模块，而不是验证它的输入输出正确性。单元测试要不要把每个模块放到真实的事务或者并发环境下测试？不要。因为你只是描述当前模块的实现，真实环境下的正确性由集成测试和QA来保证。为什么模块内部实现的变化要同时导致测试变化？因为你的思路、你的设计变化了，你应该有一个文档描述这件事情。