I've recently participated in a number of after-the-fact code reviews. Developers are supposed to be writing tests first, and are supposed to ask for help when they're not sure how to do so. Here's what it looks like:

C = one unit of time spent coding
T = one unit of time spent testing
I =  "    "   "   "    "   in an inspection or review meeting
R =  "    "   "   "    "   doing rework based on results of review
x =  "    "   "   "    "   doing other work

CCCC xxxx TTTTT xxx IIIII RRR II

We're obviously in TAD (test-after development) mode here. Pay attention to the right hand side, which roughly indicates: When could this code actually ship?

Note that there are multiple Rs because many people are involved in the review meeting. Also note that there is a little more time spent on testing, and yet the coverage never ends up good enough (rarely more than 75%). And finally, note the rework and re-inspection that must take place.

What the same model looks like with TDD:

TCTCTCTC xxxx IIII xxx RR I

So, a little less time building the right code in the first place, and also means a little less time in rework. It also means a little less time in review meetings, since the tests can help effectively describe whether or not the developer captured the requirements correctly.

With pairing and TDD:

TTCCTTCCTTCC xxxx xxx

I've doubled up the Ts and Cs because there are now two people involved. I'm not even going to claim that pairing developers will produce a better solution faster, even though I've seen this to be the case. Note that this is now the shortest line by far. (It will even accommodate some amount of formal review--much smaller now because it's already been actively reviewed at least once and preferably twice by the pairs building it--and still be shorter than the original process.)

I'm also not accounting for "ramp-up" time wasted. The intervening xxx's in the inspection-based flow means that minds have moved on to other things. When it comes time to review code, or rework it, developers must put their head back around something that they might have done days ago. Particularly without good tests, this can waste considerable time.

I'm in an environment now where test-first is only beginning to take roots. Every day I see ample evidence why test-after is simply a bad, bad idea.

posted by Jeff L.  # 3/26/2009 10:14:00 AM Database TDD Blogs