Listen to this post
Most organizations have some type of reporting mechanism allowing customers to alert them to defects they have encountered. Typically, a “trouble ticket” or similar artifact is generated, and someone is assigned the task to 1) locate and then 2) fix the errant code.
TDD views this very differently.
In TDD, a “defect” is code that causes a test to fail after development was thought to have been completed. If buggy code makes it into production and is released to customers, this is not a defect. It is a missing test.
The critical task at this point is to determine what test was missed. We actually do not want the production code to be fixed at this stage, because once we find what we believe to be the missing test, we want to be able to:
- Write the test.
- Run it and watch it fail.
- Make it pass by changing the production code (only).
Because the test is made to pass solely by changing the production code, we can be sure we have indeed written the correct test. This is a more valuable way to deal with a defect because once the test is in place, the defect can never return as we do not release code which has failing tests. It is “permanent” debugging.