I see an emmerging field, Test Driven Bug Resolution (TDBR).
I’m kidding of course, I don’t expect to see this on the agenda in Denver next year. I do see need for mention. I see developer’s riguoursly write test code prior to their build, running the test, smiling all the way. Everyone is happy. Then it happens. The business call in with a potential bug. They outline they steps they took to cause the problem, the developer feverishly taking notes.
What happens?
Our developer jumps into the application code, into the suspected class and starts dreaming up the changes. A change in the sequence of events, a change to the process or maybe just checking to see if an object is null before proceeding, what can that hurt?
This means two things to me:
1) The initial tests were light in at least one case
2) Developers consider TDD something that is done for the build, not for support.
I’m guilty. When a bug is discovered, I fall into that state of shame. I want to do whatever I can to prove my technical worth to the client and that usually means trying to tell them what it was, how I can fix it, why it happened….we’ve all been there.
The next time this happens, go into your test suite first. Try isolating the test that failed to expose this bug and change that first. Two things will happen:
1) The next time you write a similar test case, you’ll nail this exposure
2) Your test suite is that much stronger, a better story to give your client — your technical worth proven 
Posted by Jamie McIlroy 
