Test-driven development

Test-driven development is the practice of writing unit tests before you write the code that makes the tests pass. Also known as test-first development. Sometimes I do what I call test-concurrent development - I write the test case after the code, but I always have a test case before I go on to the next bit of code.

It's really a great way to work. When I write the tests a little bit at a time it isn't a chore, it just flows with the code. Sometimes it feels like I am playing a game with myself - make a move as 'tester', then make a move as 'coder'.

The constant, positive feedback gives me a great feeling of accomplishment. I know I am writing code that works because the tests are passing.

Test-first coding also has a major positive impact on the structure of my code. I write code that is more modular and loosely coupled with the rest of the system. If I have to do any refactoring I can do it with confidence that I didn't break anything.

The code is more likely to be reusable. In my experience, code is not reusable until it has been reused. Well, if you have a test suite for the code, it already has two clients - the production client and the tests - so it has been reused.

If you are writing your tests after the fact, you should give this style a try. It's a completely different experience.

For more info see CodeUnitTestFirst