This is the start of a bit of an experiment for me. TDD is something I've heard a lot about, but never actually sat down and worked out, so I'll start this series of posts just with a little introduction to what Test Driven Development is, how it differs from normal development and why it's useful.

TDD is pretty much exactly what it sounds like. When developing an application, you'd normally design a bit of functionality, develop it and then write a unit test, using a unit testing framework such as nUnit, to... (surprise) test it. With TDD, you write a test for your functionality, run it and let it fail, then you develop until your test passes. Probably your first question would be: what's the point? Why write things that way round?

The advantages are pretty clear:

• You set out what the functionality needs to do before you start writing it, almost like a specification within the code itself
  
• The code becomes easier to understand in the context of the tests. You can see all the things that the code is meant to do by reading through the unit tests
  
• You end up with a large number of automated tests that you can run, massively reducing debugging time

I've heard it said that once people start developing in this way, they find it very difficult to go back to the old ways. So, over the next few weeks, I'm going to find out how true that is.