What do we usually do when we are given the task of fixing a bug. We start with root cause analysis, this is the general instinct that kicks in, when facing a bug. Not when you are doing TDD, not on the watch of XTreme Programming.
XTreme programming advocates that developers should do things in a certain way, to be able to function smoothly and eventually have a shorter time to market. It is opinionated and strict about developer practices. One of those practices is doing Test Driven Development. In this era of software development, there is enough recognition and accolades given to TDD, and yet there are people who believe its a waste of time.
Assuming you have a fully functional team following XTreme Programming guidelines and doing TDD on a day to day basis, How would you fix a bug using TDD? These are the set of steps that you may follow to fix a bug using TDD :
- Reproduce the bug by introducing a failing End to End Test (Could be an integration test or an acceptance test, which not only limits to a single component).
- Try reproducing the bug at unit level, by writing a failing unit test or multiple failing tests asserting that it is indeed an intra component failure.
- If you could come up with a test, that fails at unit level to reproduce the bug, then fix the bug at unit level, see if there are more tests(safety-nets) that you could introduce to cover boundary conditions.
- See if your fix that passes the previously failing unit test, also passes the end-to-end test you wrote in step 1. (If not there is probably other problems, like configuration or maybe some other sub component which can also accommodate a failing unit test). If it passes then remove the end to end test, as the fix has nothing to do with integration – or keep it if it had.
- If you cannot find a way to introduce a failing unit level test in any component to reproduce the behaviour (un desired behaviour) then the problem probably lies in the configuration of your integration. If even your configuration is correct, then it is probably a false positive, or a contract broken by a third party, in which case you could still write a contract test, and a health check to avoid this in future, and have a clear indicator of what exactly failed.
This is the broad overview of how you should try to fix the bug using TDD. Then again there are exceptions like – If test is already there, but is not probably covering the behaviour thats failing, or some failure in infrastructure, but more or less this method will live up to XP’s philosophy(never repeat your mistakes, test everything) of fixing the bug in a way that ensures, that this will never happen again (Protection by test you just added).
Let’s end this article here, with a quote from Kent Beck.
“However, most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time.” – Kent Beck, Extreme Programming Explained: Embrace Change
Happy Bug Fixing.
Thanks,
Chinmay Apte
