The testers or users have reported a bug in an application that has been written using TDD. How do you go about fixing the bug?
Here’s what we do. Create a normal User Story about the bug. It will be prioritised and estimated on in the normal way.
Because we all know the application, we can quickly identify the offending class and usually the exact method that will be causing the problem.
Here’s an example of a bug, “I entered two amounts of 100 and 160. I had set the tax rates at 20% for any amounts less than 150 and 25% for amounts of 150 and above, I would therefore expected the result to be 320. The screen result actually displayed 312.
Based on the details in bug report, we create a failing test (same sort as used during TDD), to confirm the findings of the tester. The test will fail with something like: “Expected 320, actual 312”.
Now that we’ve got the failing test we can get into the actual code and fix the bug.
We name the test so that it includes a bug reference. Such as:TestTaxCalculator_Bug123_DifferingTaxRates()
The test becomes part of the part of the suite of automated tests that are performed each time on a check in.
When we update the bug report, marking the bug as fixed, we will included a reference to the test such as “Please see test TestTaxCalculator_Bug123_DifferingTaxRates()”. This gives an audit trail and helps other Developers if something related to the bug occurs.
As a team we will then discuss how this sort of bug occurred. How was that set of conditions not covered during normal TDD? What can we do to prevent similar bugs?
At the time that the bug is fixed, the developer(s) should check all the other tests that cover the offending method and review any assumptions in those tests.