| COLUMN |
Can test-driven development drive developers to test? |
 |
By Jennette Mullaney
17 Dec 2007 | SearchSoftwareQuality.com
|
Test-driven development (TDD) is gaining acceptance in the software industry. Last week Colleen Frye examined views on TDD in "Barriers remain for test-driven development."
Those who might dismiss TDD as too extreme should be relieved to know that, as with any methodology, organizations adapt TDD to their unique needs. One adherent says he uses TDD as more of a guide and admits that he doesn't write tests first. Stelligent CEO and TDD enthusiast Burke Cox encourages test-driven developers to test first, but ultimately he leaves it as a matter of "internal debate."
One of the barriers mentioned by Cox is developers who don't want to test. I think this is a strawman argument. The majority of developers seem to want to test. Those who don't know how to test are eager to learn, filling up testing classes. As we move further away from waterfall, the groups involved in software development are forced to answer to one another. Testers and developers are no longer isolated.
TDD is not for everyone -- not by any means. But it does produce testable code, and this is a great advantage. To say that testing is essential to software quality is an understatement. Yet testing is often rushed, underfunded, and relegated to the end of the production cycle. In a recent column, "Time for colleges, managers to focus on software testing,"Debashish Chakrabarti bemoans the status of testing. "For someone unaware of testing roles and options, it's quite natural that he would look at a tester as someone who is trying to find flaws in his code rather than someone working to ensure quality."
That outlook is not advancing the cause of software quality. Test-driven development may not be everyone's answer, but it does underscore the importance of software testing.
|
|
|
|
