TDD (Test Driven Development) seems to be gearing up to the new “best practice” for 2014 and you know there is nothing I like more than being told that there is a new (though TDD’s newness is debatable) shininess that will solve all of my problems and make me poop rainbows. To be clear, I don’t think that TDD is a bad idea. In fact, we are actively discussing how we might implement TDD where it makes sense at Fingertip Tech, INC – they key phrase there is “where it makes sense.” To be brutally honest, one of the reasons I’m writing these posts is to try to counter the “up and coming” TDD consultant trend. Oh yes, the process consultants are moving on from Agile and are trying to make TDD a fertile ground for their inflated consulting fees. It is my hope that sharing some knowledge at this point with you my dear reader will help you to not get suckered in by a smooth talking process consultant; as far as I’ve seen these people are nothing but charlatans, preying on organizations that have failed to keep their staff engaged.
Proponents of TDD claim that it will reduce time spent on QA / bug fixing and generally increase the quality of our code across the board. Unfortunately, they’ve so far failed to provide any conclusive evidence that supports those claims across the board – to be fair, there are plenty of folks offering guestimated anecdotes but those are as dubious as they sound. What I want is something like the average project has X hours of bug fixing under normal circumstances, we spent Y hours doing TDD, spent Z hours bug fixing anyway, Z + Y is either greater than or less than X. From a practical point of view, I see no reason to bother with TDD unless Y + Z constantly come out to be less than X. It is for this reason, that I am currently tracking this simple formula in our TDD projects.
I’m also tracking a few other factors: platform, client-side, server-side, testing library, and the nature of the bugs that we still end up having to manually test. Though I’ve been doing this personally for a few months, I am still not prepared to release my full results.
I will, however, say that TDD (at least in my experience) is looking to be like Agile in that a little bit of a good thing is good but a lot can be terrible. I’ll also share a few more points. The first being that TDD for me has so far been a sunk cost in terms of time on the client-side – it is near impossible to really “test” visual elements without manually testing them. The server-side, however, has been a different story and far more positive. This makes sense, since the TDD folks tend to focus on its effectiveness for server-side platforms such as ASP.Net or Rails.
If you want to follow this series, please follow me on Twitter and add this site your RSS reader of choice.
