I spent a lot of today going through old Confluence bug reports: sifting through for all the forgotten bugs: the ones that we fixed but forgot to close, the ones that slipped through the QA cracks, the ones that are really all symptoms of some chunk of nasty, ugly code we need to drag out into a dark alleyway and bludgeon with baseball bats, but haven't had time to yet.

There was one interesting class of bugs though -- the ones that had spontaneously fixed themselves since we last looked at them. This could be:

• Because we fixed another, duplicate bug
• Because it was an issue with a dependency we later upgraded
• Because we performed the aforementioned bludgeoning-with-baseball bats on the piece of code that was causing that whole class of errors

Popular wisdom says that every defect needs a test, but popular wisdom says you write that test to check for the behaviour that you want to happen. So when that test goes green, you know you've fixed the bug.

Those tests are fine if you're going to fix the issue immediately, but often commercial reality says you're not. Then you're in trouble because (a) all our tools are predicated on tests that start green and stay green, and (b) you can't maintain such tests effectively. How do you tell that the test still works? It can't exactly go more red than it is now.

The solution, perhaps, is the anti-test. Write a test that verifies the bug. One that goes green when the application is misbehaving in the way that you expect it to misbehave. Make sure you annotate it with the issue that it's verifying. That way your continuous integration environment will let you know immediately if something's suddenly worse than it was before.

Or perhaps, when something is spontaneously better.

It's not often a developer gets to practice optimism.