忘掉调试器吧,来使用“Saff Squeeze”

  • Mike Bria
  • 张龙

2008 年 11 月 29 日

话题:Java敏捷.NET语言 & 开发文化 & 方法

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 的内联功能。

你觉得这种方式会将你从调试器中解脱出来么?你认为这种方法有风险么?你用什么办法来处理类似的事情呢,或者同时还采取不同的方式?如果有的话,欢迎大家的讨论。

查看英文原文:Forget Your Debugger, Use The "Saff Squeeze"

Java敏捷.NET语言 & 开发文化 & 方法