Test Driven Development as a cure for Programmer’s Block

I was looking at a blank screen trying to wrap my mind around ways of moving some of the ephemeral data that Zimbra currently stores in LDAP into SSDB. Setting aside the part where most of SSDB documentation is in Chinese, that’s not too big of a deal, but I was just drawing a blank… Should I start with a Factory class? Do I need to maintain a singleton instance of JedisPool?… Until I remembered TDD. OK, I thought, this is a good opportunity to go back to the basics, despite what the creator of Ruby on Rails wrote 2 years ago (TDD is Dead Long Live Testing). In any case, I’ve clearly gotten too lazy about writing tests first. So instead of looking at a large task and trying to figure out where to start I switched my perspective to that of someone (or rather something) that will be using my adapter. What is the first thing it will need to do? Ah, write an attribute to the storage. So I wrote a failing test that is assuming that it can pass an attribute and a value to my adapter for that to be saved in SSDB. What’s next? Obviously – read an attribute from SSDB. In 10 minutes I had a basic set of tests. Now, all I had to do is make those tests pass one by one. I didn’t need to look for a starting point – I was already building. Once I implemented “set” and “get” methods one by one I was able to see what else is needed and by the end of the day I had a working subset of functionality. A week later most of the code I’ve written in the first day was completely re-written, but still everything was well tested and guaranteed to be functioning.

Comparing this experience to writing code first, adding tests second, then re-writing code third to fix the tests, I think TDD is actually saving a lot of time on catching mistakes early. I am sure that taking it to an extreme and writing a unit test for every method and function leads to over-abstraction as David Heinemeier Hansson wrote, just as it is with taking any principal to an extreme. Still, thinking from a perspective of someone or something that will use your code before writing it seems to help eliminate quite a bit of waste and save time.