In Jeff Langr’s blog, Jeff responded to an assertion (from someone Jeff calls Schmoo) that writing tests after developing a unit of production code takes less time than using TDD to create production code and its tests. For starters, I am happy the discussion is about when to write the unit tests and not if.
I think a model would help us talk about this issue. It would be great to have some real numbers in the model; that will be hard. But for starters let’s look at a model. Maybe then someone can figure out how to put some numbers to the model.
If we are just interested in the production and test code time and not other factors, like better design and its future savings (but I am interested in this), we can look at these areas where time is spent:
“Done” for both TDD and TAD is the some of these factors
Schmoo’s assertion, if I have it right, is the TTAD-Done < TTDD-Done. Jeff’s asserts the opposite.
Schmoo thinks TTestCode for TAD is less because less tests are needed. I think he would also argue that TProdCode is also less because you can just write the code and don’t evolve it line by line.
Jeff points out that with TAD, the test and fix cycle (TFindMistakes + TFixMistakes) will generally be longer. It will be harder to find problems revealed by the tests in TAD. Let’s dissect that assertion:
Neither Jeff or Schmoo mention the lifetime cost of mistakes that are not discovered by either TAD or TDD. TManageFindAndFixBugs is hard to quantify. I would assert that the thoroughness of the TDD tests would result in fewer mistakes that become future bugs.
My experience is that TDD reduces TFindMistakes and TFixMistakes. Schmoo might argue that time is negated by having less tests and writing the production code all at once. That’s not my experience so I would say that TDD wins or at least ties TAD. When we factor in TManageFindAndFixBugs, I think TDD is a clear winner. Why? The average cost of managing, finding and fixing bugs is high. More mistakes slip by TAD than TDD.
If we had some real numbers, maybe we could prove it. But again, I’m glad we are talking about when and not if tests should be written.