TDD is total crap

Okay, that's really just a hook to get you in the door. Let me complete my thought:

TDD is total crap if you don't really do TDD, but get stuck on Faux-TDD

In the last four weeks the project I'm working on has grown from 3 libraries to 12 (it's probably a bit bloated).  It has gone from 30% unit test coverage to about 75% unit test coverage.  (The white-papers I've skimmed more or less say 70% to 80% is good and that getting above that is not cost effective unless you're writing fighter-jet or medical device software.)   We're successfully implementing an MVP based on the in-depth work Vijay did looking into approaches.  We are coding against interfaces not implementation classes, using an IOC tool and writing unit tests using a mocking framework.  And, most importantly, we're trying really hard to implement TDD.

I'm going to go ahead and say, we've done everything we can in he way of employing tools and patterns to make TDD happen - save one thing: writing tests before we code.  This is kind of the classic Software Engineer response: learn a tool, get some numbers, bang some stuff out to get it going.

So, back to the hook.  TDD is crap if you don't actually do it, and it is hard to do.  I'm just not there yet and I'm starting to realize I need to do it, or forget about it and go back to Code-QA-BugFix.  I've concluded there is not middle ground on this one, either do it or don't.  Writing tests after you code just validates the assumptions you used to write the code.  Writing tests after you code delivers a bulk of tests that bog down what you are trying to ultimately accomplish and encourage you to waste time making "pretty" tests.

So what makes me so high and mighty?  Well, failure.  I have yet to really get traction on TDD. But, as you can tell, I have all the tools a software engineer could want and I'm out of excuses.  What I have come to understand is what TDD is offering me.  TDD is going to keep me from writing extra code - I'm only going to write enough to pass the test.  TDD is going to keep me from writing a bunch of tests that affirm my assumptions.  TDD is going to give me leaner software and more velocity in the long run.  Now all I have to do is butch up and really do it.  So, I'm off to change how I think about and do the simplest part of my job, put my fingers to keyboard. And while the tools are a great help and in place, I'm on my own here.

PostScript: I feel I would be remiss if I didn't offer a caveat.  Moving to TDD, as I am in the throes of, is a process.  Writing tests after coding has gotten us to the 75% mark on test coverage and flexed our unit test writing muscles and taught us how to mock without being a mockery.  That being said, if we were to stall out here in Faux-TDD and declare victory without pushing through to the land of TDD milk and honey we'd be guilty of adding a wicked inefficiency to our work.  So moving from Code-QA-BugFix to TDD may require spending some time in that middle place of Code-then-Test finding your way, just don't setup camp.