XP、TDD 及 JUnit 的联合创始人 Kent Beck 谈到了他通过单元测试而不是调试器来跟踪到 JUnit 的新特性 JUnitMax 中一个缺陷。他使用了当前 JUnit 的主开发者 David Saff 向其展示的一个方法,该方法首先创建一个高层的单元测试,然后不断回归直至缺陷的根源处,这时的测试就会变得非常简洁明了。
Beck 通过一个比喻介绍了这个他称之为“ Saff Squeeze ”的方法,该比喻来自美式橄榄球中出现的“三明治”,在这里面带球的人会同时被两个人所击中,一个人击打其“高位”(肩膀附近),另一个人击打其“低位”(腰部或腿部)。他说“Saff Squeeze”与此类似,因为这种方法首先会编写一个失败的高层单元测试(“高位”),然后不断回归,用更加具体的单元测试进行替换(“低位”)直到某个单元测试能直接找出有问题的代码(也就是直到能“揪出”缺陷)。
Beck 对该方法的总结如下:
Saff Squeeze 是这样运作的:首先我们需要编写一个失败的测试,然后逐渐向底层深入直到无法再进行下去为止,这时你就会发现缺陷的本源了。下面是循环的过程: 1. 在测试中内联一个出错的方法。
2. 将一个(失败的)断言放到测试中已有的断言前。
3. 移除测试中新断言到原断言之间的部分。
4. 重复上述过程。
在一篇简短的文章中,Beck 讲解了上述过程,展示了不同阶段的测试代码,最后展示了一个“精简的”测试,该测试揭示出了实际的缺陷。
他将这种方式与传统的通过调试器来跟踪代码的方式进行了对比,总结如下:
这两种方式的一个主要差别在于进行调试后,我知道了缺陷在什么地方,但是在精简后,我还有一个针对该缺陷的最小单元测试。这个精简的测试是随着整个过程的进行自然而然产生出来的。
Beck 说他并没有将这种方式看作是对新代码 TDD 开发周期的一个补充或是改变,而是进行缺陷处理的一个工具:
它将成为识别并修复缺陷的方法的核心: 1. 通过一个系统级测试来重现缺陷。
2. Squeeze。
3. 让这两个测试都能通过。
4. 分析并排除缺陷的根源。
请阅读这篇文章来看看在一个实际的例子中这会是什么样子的,同时更多的了解Beck 对这种技术能力的看法并掌握Eclipse 的内联功能。
你觉得这种方式会将你从调试器中解脱出来么?你认为这种方法有风险么?你用什么办法来处理类似的事情呢,或者同时还采取不同的方式?如果有的话,欢迎大家的讨论。
评论