Kent Beck, co-father of XP, TDD, and JUnit itself, tells a story about tracking down a defect in a new JUnit feature, JUnitMax, with unit tests instead of a debugger. He explains a method shown to him by current JUnit lead developer, David Saff, where a high level unit test is recursively inlined until a super concise test exists at the root of the defect.
Beck introduces the method he's dubbed the "Saff Squeeze" by drawing a metaphor to an American Football occurrence known as "The Sandwich", where the ball carrier is hit simultaneously by two people, one hitting him "high" (up near his shoulders) and another hitting him "low" (at his waist or legs). He explains the "Saff Squeeze" is similar to this in that one approaches addressing a failing high level unit test (the "high tackler") by recursively replacing it with more and more specific unit tests ("low tacklers") until a test exists that directly identifies the problem code (ie. until the defect can be "tackled").
Beck's summary description of the method:
He compares this approach to the more traditional approach of walking through code with a debugger, concluding the following:
Do you see this helping you free yourself from your debugger? Do you think the approach runs any risks? Do you have stories about how you've done something similar, or taken a different approach altogether? Add to the discussion here.
Beck introduces the method he's dubbed the "Saff Squeeze" by drawing a metaphor to an American Football occurrence known as "The Sandwich", where the ball carrier is hit simultaneously by two people, one hitting him "high" (up near his shoulders) and another hitting him "low" (at his waist or legs). He explains the "Saff Squeeze" is similar to this in that one approaches addressing a failing high level unit test (the "high tackler") by recursively replacing it with more and more specific unit tests ("low tacklers") until a test exists that directly identifies the problem code (ie. until the defect can be "tackled").
Beck's summary description of the method:
The Saff Squeeze, as I call it, works by taking a failing test and progressively inlining parts of it until you can't inline further without losing sight of the defect. Here's the cycle:In the brief article Beck walks you through this process showing the test code at different steps, finally showing a "squeezed" test that spotlights the actual defect in all its glory.
- Inline a non-working method in the test.
- Place a (failing) assertion earlier in the test than the existing assertions.
- Prune away parts of the test that are no longer relevant.
- Repeat.
He compares this approach to the more traditional approach of walking through code with a debugger, concluding the following:
One key difference between the two processes was that after debugging I knew where the defect was, but after squeezing I had a minimal unit test for the defect as well. That concise test is a handy by-product of the process.Beck clarifies that he doesn't see this as an addition or change to the TDD development cycle for new code, but rather as a tool to be used for defect resolution:
It would work as the heart of a disciplined approach to identifying and fixing defects:Read through the article to see what this looks like in a real example, more on Beck's opinion of this technique's applicability, as well as a gripe about Eclipse's inlining capabilities.
- Reproduce the defect with a system-level test.
- Squeeze.
- Make both tests work.
- Analyze and eliminate the root cause of the defect.
Do you see this helping you free yourself from your debugger? Do you think the approach runs any risks? Do you have stories about how you've done something similar, or taken a different approach altogether? Add to the discussion here.
