TDD: the Failed Panacea
This post was imported from blogger, to see the original, likely better-formatted post see kalebpederson.blogspot.com.
>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:
.addOptionalArgument(“answerId“, DataTypes.INT, 42)
// 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 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.