TDD: the Failed Panacea

Yes, I admit it.  TDD is not a panacea; it fails as a cure-all. Some bigots might claim it is (and, yes, I probably sound like a bigot every now and then), but TDD isn't perfect.

Over the last few months I've been working on a compiler at Soph-Ware Associates. The compiler supports annotations mostly identical in syntax to Java's annotations.  After a few hours using acceptance test driven development (ATDD), I had developed a nice structure for defining annotations using builders:


builder.withAnnotationName("AnnotationName")
.addRequiredArgument("attributeId", DataTypes.STRING)
.addOptionalArgument("answerId", DataTypes.INT,  42)
.build();
// arguments can also be created with builders if desired


My next step was to query various data from the annotation to be used in the compilation process, but I couldn't find a way to refactor my previous definition and validation work to retrieve the needed data. All the information was there, sort of, but not in a way that was amenable to refactoring.

TDD Failure

TDD had failed me. Okay, unlikely. TDD cannot force me to take into consideration everything I need consider.  Had I spent a bit more time thinking about the information I would need later, and less about up front validation, I may have realized that had I done things differently, I may have been able to accomplish both quite easily. TDD didn't force me to use the validation algorithm I did.  In fact, the more I think about it the more I believe I failed at closely adhering to the single responsibility principle, as applied to functions.

Even though TDD isn't the panacea I might like, at least I reap the benefits of its other strengths.