Dave Schweisguth in a Bottle

The software community’s understanding of developer testing (unit testing, acceptance testing, etc.) has come a long way since “Extreme Programming Explained” and “Refactoring” and JUnit got everyone interested almost fifteen years ago. There was a time when developers argued whether unit testing was valuable (never mind TDD); now it’s taught in code camps as an essential skill.

But some testing techniques have remained out of the mainstream, for whatever reason. A couple of them came up on Stack Overflow recently and I was inspired to give long answers. Whether or not these techniques eventually become part of standard practice, they’re interesting to know about and possibly useful in shaping your thinking about mainstream practices.

The Saff Squeeze

Kent Beck described the engagingly named Saff Squeeze in a 2008 blog post. It is a structured way of carving down a failing test until it’s small enough to understand. Someone had trouble understanding Kent; I provided an exhaustive example of using the Saff Squeeze on a simple test of simple code. Although I only use the Saff Squeeze when I can’t figure out where to set a debugger breakpoint, it’s also useful as an analogy of what we do when we set a breakpoint earlier and earlier in a program to home in on the problem line.

Invariant detection, Agitar and Observation-Driven Testing

About ten years ago I evaluated a revolutionary Java testing project, Agitar’s AgitarOne. (That’s the current name; it might have been different back then.) It came as close as I’ve ever seen to automatically writing tests after the code was written, by executing all your code and looking for invariants. At some point Agitar gave use of their tool the name ‘Observation-Driven Testing’ (perhaps to parallel the many TLA methodologies and techniques with ‘Driven’ and/or ‘Test(ing)’ in their names), and someone asked about that. I described what I’d seen of how Agitar’s product worked.

Not only is invariant detection very powerful and interesting to watch, it contributed to my mental model of testing. To expand briefly on a comment from that SO answer that should probably be its own article somewhere, a unit test maps a member of a set of combinations of qualitatively different inputs (including both the initial state of the system and the method parameters) into a member of a set of qualitatively different outputs (including the final state of the system and the method’s return value or exception). It’s the “qualitatively different” part that makes testing possible by constraining the number of tests you have to write. Without “qualitatively different”, that description is a one-line version of a very clear description of object-oriented computing that I saw once and still remember but can’t find again. Maybe somewhere in the 1200 pages of Meyer’s OOSC?

Two finds make a collection, to which I’ll be looking for more testing oddities to add. Maybe it’s time to reread the wiki.