Find a Bug, Code an xUnit

In today's travels, I ran into an important bug in a new feature that had been missed in test. One reason for the late discovery was that setting up and re-creating the problem in "black box" mode was time-consuming: change profiles, load and decision new work, complete a full processing cycle, create end of day files, and so on. Yet at its core, it boiled down to only four possible permutations of inputs through a single business object method, and one of these four behaved badly.

This was, of course, the perfect opportunity for an xUnit: a short method could test all four permutations and prove the bug. So, in classic TDD fashion, I coded the test case first and then fixed the business object to turn yellow to green. This bug had escaped not because creating a SUnit was difficult, but because it had been overlooked.

In any system, there are lots of test scenarios (such as deep integration) that cannot be approached by xUnits. But there are usually many more valuable xUnits that could be written than actually are. Like refactoring, there's never time to go back and add xUnits to old code just to do it. But bug discovery is the perfect opportunity, and xUnits here are not only good policy, they help with coding and verifying the fix. So, find a bug, code an xUnit.