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

XP、TDD及JUnit的联合创始人Kent Beck谈到了他通过单元测试而不是调试器来跟踪到JUnit的新特性JUnitMax中一个缺陷。他使用了当前JUnit的主开发者David Saff向其展示的一个方法，该方法首先创建一个高层的单元测试，然后不断回归直至缺陷的根源处，这时的测试就会变得非常简洁明了。

Beck通过一个比喻介绍了这个他称之为“Saff Squeeze”的方法，该比喻来自美式橄榄球中出现的“三明治”，在这里面带球的人会同时被两个人所击中，一个人击打其“高位”（肩膀附近），另一个人击打其“低位”（腰部或腿部）。他说“Saff Squeeze”与此类似，因为这种方法首先会编写一个失败的高层单元测试（“高位”），然后不断回归，用更加具体的单元测试进行替换（“低位”）直到某个单元测试能直接找出有问题的代码（也就是直到能“揪出”缺陷）。

Beck对该方法的总结如下：

Saff Squeeze是这样运作的：首先我们需要编写一个失败的测试，然后逐渐向底层深入直到无法再进行下去为止，这时你就会发现缺陷的本源了。下面是循环的过程：

2. 将一个（失败的）断言放到测试中已有的断言前。
3. 移除测试中新断言到原断言之间的部分。
4. 重复上述过程。

在一篇简短的文章中，Beck讲解了上述过程，展示了不同阶段的测试代码，最后展示了一个“精简的”测试，该测试揭示出了实际的缺陷。

他将这种方式与传统的通过调试器来跟踪代码的方式进行了对比，总结如下：

这两种方式的一个主要差别在于进行调试后，我知道了缺陷在什么地方，但是在精简后，我还有一个针对该缺陷的最小单元测试。这个精简的测试是随着整个过程的进行自然而然产生出来的。

Beck说他并没有将这种方式看作是对新代码TDD开发周期的一个补充或是改变，而是进行缺陷处理的一个工具：

它将成为识别并修复缺陷的方法的核心：

1. 通过一个系统级测试来重现缺陷。
2. Squeeze。
3. 让这两个测试都能通过。
4. 分析并排除缺陷的根源。

请阅读这篇文章来看看在一个实际的例子中这会是什么样子的，同时更多的了解Beck对这种技术能力的看法并掌握Eclipse的内联功能。

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

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