TDD the truth of it all

TDD (test driven development)

One of my work colleagues recently said that TDD has had the biggest impact on development in the last decade. I don't disagree with the fact that TDD is a wonderful thing but I do fail to see how it has had quite that much impact, so I decided to look at it from another angle.

I started to think about fundamentally what TDD gives and what investment is required to get it, essentially I saw two obvious benefits:

• more stable code
• refactor with confidence

These are the two things that I am always told are the advantages of using TDD, however I've recently had the dubious pleasure of seeing code that I wrote some 4-5 years ago and it got me thinking about these two claims. Would I have written the code any differently had I used TDD in writing it?the simple answer is no. Therefore if the code I would produce is the same then it can't be more stable if using TDD that has to be a fact right?

The second thing is undeniable, if there are tests surrounding a piece of code then I can be confident that if I bodge something when refactoring then tests will fail and my CI box will flash red and shout at me that I did something wrong, like I said this is undeniable! However what if the code never does get refactored or changed? Doesn't this mean we have all the benefits but never take advantage of it? We have a Ferrari but never take it out of the garage, we can look on and say oooh look at our tests aren't they shiny but do little else. As I said previously I've looked at code I wrote for a system around 4-5 years ago and it has not been changed so if TDD had been used the initial investment won't have been realised through its benefits so the added cost of writing tests suddenly has become detrimental to the project! One big issue with this is that no one could have predicted that the piece of code wouldn't be refactored and indeed it may be the exception rather than the norm that the code hasn't been altered in some way. As I have said at the beginning of the article I am a proponent of TDD I do think it's an approach that should be adopted however looking at it from a dispassionate angle I can see certain circumstances where it doesn't benefit as much as it costs and like so many methodologies and processes with software development adopting a blind blanket application to 100% of your development is not the way to go pragmatism is the key.

So what are the costs I've talked about? My honourable work colleague would argue that there are no costs involved since writing the tests up front is your way of writing the code. However what he means is writing the test up front is his way of writing the code. My way of writing the code differs from his as I imagine it differs from many. Although rather than being unique I realised that I actually use a method described in Code Complete as the Pseudocode Programming Process or PPP for short, the only difference is that I tend to write my pseudocode in my head which I am sure is a common practice. So the costs for me are that I would be physically writing code that I wouldn't necessarily have written which would include the usual thinking/typing/documenting/debugging times that all code seems to.

Having said all this, I wouldn't want to write code that didn't have tests, I do in fact hate myself for the fact that a mere 4-5 years ago I was producing code without test as this screams of lazy developer syndrome or probably more likely screams of a less confident developer that could stick to his guns about development time frames rather than cut corners.