Why Invest in TDD? Refactoring
Why invest in TDD? Refactoring
I've been asked lately why test-driven development so important. Apparently many teams (or their management) still think of methodical unit testing as an additional luxury expense. "We don't have time for tests", "Test code can't be sold" are common arguments.
Without digging into testing methodology, architectural considerations and consequences, I'd like to focus on benefits in the broader context of development process. Most modern methods - especially agile - aim to address the problem of code decay. During a software project's life-cycle, the code quality deteriorates, and the cost of introducing new features increases significantly. Refactoring is the main means to improve code quality and protect against decay in order to keep development and maintenance costs manageable.
We can come to the conclusion that continuous refactoring should be an organic part of the development process. The main challenge is though, non-trivial refactorings are potentially unsafe. Even a carefully done refactoring has the potential to breaking functionality. Most developers - rightly - don't do unsafe operations often (otherwise they would sit in front of a debugger all day long without being productive). One of the most important goals of testing is to make refactoring safe: make resulting problems instantly apparent and easy to pinpoint. According to my experience, they serve this purpose very well.
I highly recommend the following book for reading: Refactoring - Improving the Design of Existing Code from Martin Fowler. He discusses this topic in great depth.