测试驱动开发：众人关注，讨论热烈

近日以 JavaEye 为主的技术社区发起了一系列关于测试驱动开发的讨论。从讨论中可以看出，越来越多的开发者对测试驱动开发表现出浓厚的兴趣，一些人已经在实践中总结出了自己的经验；但与此同时，各种与测试驱动开发相关的误解仍然广泛存在。

在一个题为“这样的 TDD 实践方式有问题？” 的讨论串中，作者 hyysguyang 讲述了自己在面试中遇到的一个问题：以 TDD 的方式，编写“将一个句子反转”的程序。这个看似简单的例子，却让作者 和面试者产生了很大的分歧，并引发出关于“如何测试驱动开发”和“如何重构”的大量讨论。作为对这个帖子的回复，gigix 在题为“测试如何驱动开发”的帖子中写了三个测试案例，分别测试“把句子拆分成单词”、“反转一个句子”、“反转另一个句子”的功能。

随后的讨论围绕着“TDD 和传统意义上的测试之间的区别”展开。ozzzzzz 这样说道：

测试是测试，测试驱动是测试驱动，别把两个东西搞混了。说白了测试驱动还是需求驱动，而测试则需要考虑更多的东西。gigix 的做法在 tdd 看来很棒，但是在测试角度看则很不完整。TDD 的做法并不是要你在最早就准备好一个完整的测试系统，而是要你通过写准对需求的测试，也就是针对功能的测试，来因对性的完成你的代码。这是一个由需求，转换为针对测试，再 [转换为] 因对的代码的过程。

对于并非直接功能需求的“把句子拆分成单词”的测试案例，gigix 的解释是：

这个测试就是所谓的“设计过程” 我把一个大的问题分解成两个小的问题，先用测试驱动解决第一个，再用测试驱动解决第二个。
一开始我只考虑怎么实现。我设计了一个 split 的功能，所以我给它写测试，然后实现它。实现完以后，我发现 split 显然不应该是 StringReverser 的功能，所以我重构它，把它抽取到 SentenceSplitter 类，并且把对应的测试也搬到 SentenceSplitterTest。这个时候 StringReverser 的 split 方法只是一句直接的 delegate，所以不需要测试，并 且可以直接 inline 到 reverse 方法内部去。

众所周知，测试驱动开发在大部分企业里仍然没有得到实施，更多的开发者还在用观望、了解和学习的态度看待它，一个常见的问题就是“花费时间写测试是否合算”。在题为“ TDD，想说爱你不容易”的文章里，作者 yananay 对实施测试驱动开发的成本和收益做了一个简单的核算：

一个月下来，我能运行的测试类有 140 多个……这样，每次系统改动的时候，我只要把这些测试全运行一次，就知道我负责的模块是不是有问 题。 那么其他人呢？他们仍然在手动测试……就算我那 140 个测试方法都是单独的，[编写] 每个方法我需要 10 分钟， 那么我需要 1400 分钟，1400/60 = 23.3 个小时。也就是说，一个月下来，我只需要多付出 23.3 个 小时。 那么收益是多大呢？一个月后，我只需要 20 分钟就可以知道系统是不是存在错误，而他们却 需要几个小时，而且未必准确。

James Zhao 在讨论中对测试驱动开发做了一个很好的总结：

既然是测试驱动，那么，TDD 就和需求关系紧密，至少距离需求比较近，而不是传统的那些开发过程，测试排在最后。软件最终由程序员写代码实现，所以程序员需要理解需求，实现系统功能，把问题解决在自己的范围之内，因此是不是测试驱动开发，程序员自己的测试都很重要，而测试驱动开发就更向前走了超前的一步，保障软件的质量，开发的效率。 至于风险，应该说随着软件开发方法、开发过程理论实践的不断发展，风险是逐渐下降的，也就是说，使用传统的开发过程，风险可能会更大。能够起到多大的作用，提高多少效率，存在多大风险，在于使用 TDD 的开发者的水平。

在文章的最后，作者 yananay 毫不掩饰地表达出自己对测试驱动开发的信心：

如果你是一个准备购买软件的客户，那么你可以毫不犹豫地要求软件开发商使用 TDD 的方式， 因为你应该知道这样做其实是在保护你的利益。如果你是一个老板，那么你应该立刻要求下属学习并实践 TDD，如果客户不买单，那么你应该 买单，因为你应该相信，微小的成本会换来更好的软件，更好的软件会迎来更多的客户。 如果你是一个开发人员，那么你应该立刻学习并实践 TDD，如果你的客户和老板都不准备买 单，那么就自己买单。你应该相信，微小的付出，会换来更多的价值！

您的看法呢？