Test-Driven Debugging

So, you're doing TDD. You're pretty happy with the results. You have confidence. You're refactoring. You're having fun.

Then someone finds a bug. In your code. Your ego deflates, you collapse in depression. Maybe this TDD thing isn't going to work. Better tell your boss to hire back all the testers he just fired.

Nah, TDD isn't about producing code with no bugs. After all, its about Development not about Testing. Buck up & get back to work. Here's my approach:

• Think about the user's bugged experience. Write a test that reproduces the broken behavior. Write it in the easiest way possible, without having to understand why the bug exists. That can be several objects away from the site of the bug.
• Run the test & see that it fails.
• Come up with a hypothesis about why the test is failing. Write test to check your hypothesis, typically by testing a small part of what happens in the previous test.
• If it passes, come up with a new hypothesis & repeat.
• If it fails, drill in further & repeat.
• Continue until you can fix the bug with complete confidence.
• Fix the bug & verify that all unit tests now pass.
• Think about other places where you might have made a similar mistake. Add tests to find out & motivate the fix.

Now comes the really important bit: the learning. Think about why this bug happened; what thinko resulted in this broken behavior. Don't scold yourself, just understand it. Now, free yourself from the burden of this bug by using your new understanding to improve the unit tests you write in the future.

There, now you've debugger the code and yourself!