忘掉调试器吧，来使用“Saff Squeeze”
作者 Mike Bria译者 张龙 发布于 2008年11月29日 下午10时54分

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

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

Beck对该方法的总结如下：

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


在测试中内联一个出错的方法。
将一个（失败的）断言放到测试中已有的断言前。
移除测试中新断言到原断言之间的部分。
重复上述过程。
在一篇简短的文章中，Beck讲解了上述过程，展示了不同阶段的测试代码，最后展示了一个“精简的”测试，该测试揭示出了实际的缺陷。

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

这两种方式的一个主要差别在于进行调试后，我知道了缺陷在什么地方，但是在精简后，我还有一个针对该缺陷的最小单元测试。这个精简的测试是随着整个过程的进行自然而然产生出来的。
Beck说他并没有将这种方式看作是对新代码TDD开发周期的一个补充或是改变，而是进行缺陷处理的一个工具：

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


通过一个系统级测试来重现缺陷。
Squeeze。
让这两个测试都能通过。
分析并排除缺陷的根源。
请阅读这篇文章( http://www.threeriversinstitute.org/HitEmHighHitEmLow.html )来看看在一个实际的例子中这会是什么样子的，同时更多的了解Beck对这种技术能力的看法并掌握Eclipse的内联功能。

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

查看英文原文：Forget Your Debugger, Use The "Saff Squeeze"
http://www.infoq.com/news/2008/11/beck-saff-squeeze

——正好想深入的js就缺少调试跟踪的工具，不知道能不能借用这个方法。。。。。。可惜有人评论道：
不要在OO和TDD的路上走太远，忘记了编程的本质
2008年12月1日 下午8时40分 发表人 Andy Huang

JUnit虽然好，但是不是万能的膏药。这些技术偏执狂，有时候过分的偏激和钻牛角尖了。

对于简单的bug，这种方法是可行的，但很多复杂的程序，用这种方法，怎么也找不到bug的，调试器有时候是必不可少的。