I recently read a blog post by Joshua Lockwood where he spoke of some people who claim they don’t have time to test.

Learning the TDD approach to writing code has been one of best things that I’ve learnt over the last few years - before I worked at ThoughtWorks I didn’t know how to do it and the only way I could verify whether something worked was to load up the application and manually check it.

It was severely painful and on one particular occasion I managed to put some code with a bug into production because I didn’t know all the places that making that code change would impact.

It’s not a good way of working and I’m glad I’ve been given the opportunity to work with people who have showed me a better way.

My experience pretty much matches a comment made by Chris Missal on the post where he pointed out that you are going to test your code anyway so you might as well automate that test!

I’ve just spent the last 2 hours doing some refactoring on an F# twitter application I’m working on and because I didn’t write any tests it’s been a very painful experience indeed.

Every time I make a change I have to copy all the code into F# interactive, run the code and then manually make sure that I haven’t broken anything.

I’ve been doing this in fairly small steps - make one change then run it - but the cycle time is still much greater than it would be if I had just put some tests around the code in the first place.

I think we should be looking to test more than just the 'complex code' as well - there have been numerous occasions when I’ve put the logic for a conditional statement the wrong way around and a test has come to the rescue.

It pretty much applies to all the languages that I’ve worked in and if we can’t see how to easily create an automated test for a bit of code then it’s a sign that we’re doing something wrong and we might want to take a look at that!