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