My thoughts on Test Driven Development

A few years back my work decided to roll out the use of Scrum to manage the teams of developers. This has worked well for the most part but we have so far not taken on any of the XP techniques that most Agile Scrum teams are using. This will soon change as a continuous integration system is being built and Test Driven Development (TDD) is beginning to be rolled out.

With the start of the TDD roll out, Clarke Ching (our Agile Expert and Consultant) has pointed us in the direction of his TDD Test Drive which uses a simple example with Excel and VB to introduce the principals of TDD.

My basic understanding of TDD is that the development process changes to:

1. Write an automated test that fails

2. Write just enough code to make it pass

3. Look for opportunities to re-factor the code

4. Make sure all the tests still pass

5. Repeat steps 1-4 until all tests are written and pass.

My initial thoughts on TDD are that whilst bringing huge benefits over traditional manual unit testing (especially where we have a large number of versions of the software being maintained using branches and roll ups), I am worried about missing important tests that will drive the software in the wrong direction. I am also worried about how to apply it to legacy code - There could be a large amount of re-factoring required which will impact our delivery time.

What I mean by missing important tests is that the tests are often based on the requirements or description of a bug that has been found in the software. Most of the time requirements and bug descriptions are vague or do not tell the whole story - if these are the sole drivers of the tests and the code is only written to make these tests pass it could be easy to miss something important.

I'd love to hear from other software developers on their thoughts and experiences with TDD and I'll let you know how I get on when I start putting it into practice.