Test-Driven Development (TDD) and software quality
From Java World
Any Test-Driven Development practitioner will tell you, Test-Driven Development (TDD) is a design strategy, not a unit-testing technique. Writing unit tests are a means, not an end. The goal is to write better quality, more reliable, and more accurate code.
I recently read a study in the IEEE Software journal (“Does Test-Driven Development Really Improve Software Design Quality” that tried to establish measurable benefits of Test-Driven Development on software design quality. Any TDD practitioner will tell you, using TDD properly tends to produce better quality code. Not just code that is tested better, but well-designed code.
This study looked at TDD as an isolated practice, independent of other agile practices. Indeed, TDD isn’t limited to Agile development – you can also do TDD in more traditional development processes. Just replace the “Detailed Design -> Code -> Unit Test” cycle with “Unit Test -> Code -> Refactor”.
Not suprisingly, teams that practiced TDD obtained much better code coverage statistics. But, more interestingly, the study also found that coding teams that practiced TDD tended to implement smaller, simpler solutions, with less lines of code overall, and less lines of code per method. The cyclometric complexity was also lower, which is a side-effect of simpler, more testable code. My own experience, like a lot of TDD practitioners, tends to bear these finding out. However, it is hard to come up with objective evidence, since you rarely solve exactly the same coding problem in the same conditions twice.
