Tim Bray has a great rant up, all about how fantastic test driven development is. It’s a good article and I hope it circulates — given his readership I’m sure it would. Over at Kryogenix, there’s a question as to whether people are actually actively using it. Well I have and I believe in it, so I thought I’d do a bit of a testimonial post.

In my second year of university (not that long ago), we had an entire unit that consisted of a software engineering project. We had to use the lecturer as our “average user”, conduct interviews to get the requirements and then basically go and build an online personal organiser, according to what we had gleaned from conversations with him. It was a good project, but only a part of the course and so getting 4 students to work together, cohesively and sensibly to produce the damn thing was quite a task.

One thing that we found did really work was the use of testing. The project was LAMP, so after the fairly illuminating lectures about unit testing, integration testing, system testing and then user testing, we set out to put it all into practice. We read this Harry Fuecks tutorial and adopted the Eclipse PHPUnit library. For every class we created in the design, we also created a number of tests for it. And we wrote the tests for PHPUnit often before the code itself.

Sounds like a lot of hassle? Well, it certainly takes getting used to. Writing test scripts is as much an art as writing the actual code. But it was worth it in the end — for one thing we were able to check by going to one webpage that everything in our system was working before the demo to the lecturer! 😉

But the real value in this approach to development? It ensures that you are testing for the functionality you planned, throughout. If you write the tests when you design the system, then you’re definitely testing for what it ought to do, rather than what often happens where someone bodges some code, works on it and eventually changes its purpose, so a requirement is lost and the test (written post implementation) of course returns OK because it is testing that what is there works … not that what is there is the right thing and works.

And for me that’s the real benefit of TDD — it makes sure that I build the right thing and that it works.