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

作者 Mike Bria 译者 张龙 发布于 2008年11月29日

领域

语言 & 开发,

过程 & 实践

主题

单元测试 ,

质量交付 ,

Java ,

敏捷 ,

.NET

标签

JUnit ,

调试器 ,

测试驱动开发

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轻量级框架有一定研究。

1. 返回顶部

   软件工程就是从技巧向技能的转变

   发表人 Li bouzouki

   技巧不仅是对工程的阻碍，事实上也是对开发者的束缚，当越来越多的技巧转化成技能，开发者就能释放出更多的创造力。

   回复

2. 返回顶部

   翻译得不太好

   发表人 Shan Yang

   Inline a non-working method in the test.
   在测试中内联一个出错的方法
   
   Prune away parts of the test that are no longer relevant.
   这个实际上就是移除新断言到原断言之间的部分

   回复

3. 返回顶部

   Re: 翻译得不太好

   发表人 张 龙

   你好，谢谢你的指正，这篇新闻是我翻译的，刚才又仔细对照原文进行了检查，确实如你所说，这两个地方翻译的有问题，已经修正，再一次感谢你的指正 :-)

   回复

4. 返回顶部

   不要在OO和TDD的路上走太远，忘记了编程的本质

   发表人 Huang Andy

   JUnit虽然好，但是不是万能的膏药。这些技术偏执狂，有时候过分的偏激和钻牛角尖了。
   
   对于简单的bug，这种方法是可行的，但很多复杂的程序，用这种方法，怎么也找不到bug的，调试器有时候是必不可少的。

   回复

5. 返回顶部

   过犹不及

   发表人 Shao Tony

   请问有效率和效果的评估吗？

   回复

• 更早的 >