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

作者 林芷薰 发布于 2007年9月24日

领域

语言 & 开发,

过程 & 实践

主题

敏捷技术 ,

敏捷 ,

单元测试

标签

重构 ,

极限编程 ,

敏捷介绍 ,

模式与实践

近日以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，如果你的客户和老板都不准备买 单，那么就自己买单。你应该相信，微小的付出，会换来更多的价值！

您的看法呢？

• 更早的 >