March 6, 2021
Hot Topics:

Considering Test-After Development

  • By Jeff Langr
  • Send Email »
  • More Articles »

It took me 15 seconds to build this solution, but perhaps this is a legacy of having already solved the problem once. (Still, I sometimes find that the solution is more obvious in the smaller context that TDD often promotes.) But, for sake of a fairer comparison to the TAD solution, I'll say it took me the same 30 seconds to build it.

The final test, for now (20 seconds):

public void reversesManyWords() {
   assertEquals("three two one",
                reverser.reverse("one two three"));

Now, with all of the other special conditions and edge cases in place, I still need a loop, and much of the original TAD solution (90 seconds):

public String reverse(String text) {
   if (text == null)
      return null;
   String[] words = text.split("\\s+");
   StringBuilder builder = new StringBuilder();
   for (int i = words.length - 1; i >= 0; i--) {
      if (i > 0)
         builder.append(' ');
   return builder.toString();

All six tests pass.


Did I spend more time building the TDD solution? You bet, but not by much. By using TAD, did I introduce a potentially devastating defect into the code? You bet. And if I had remembered to add the missing tests after the fact, and had fixed the problem in the TAD solution, the solution times would have been about the same between TDD and TAD.

Here are the times for building each solution, based on the step times that I tracked above:

TAD: 3 minutes 45 seconds + 1 defect (45+120+30+30)
TDD: 4 minutes 55 seconds + 0 defects (30+10+30+10+15+15+30+15+30+20+90)

Fascinating. Note the step times involved for each solution. Derivation of the TAD solution is more erratic, while the TDD solution demonstrates a more consistent, almost rhythmic, pace.

It took me a minute longer to build the TDD solution. My tradeoff: the ability to ship code with high confidence that it actually works. In a short-sighted world, where we look at only time to deliver, TAD works "just fine." But in the "real world," where we willingly ship software of poor quality, we pay for that one minute tens, hundreds, perhaps thousands of times over. I remind myself that it takes only a little more initial time to craft quality code.

It's theoretically possible to write as many tests using TAD. But often, developers don't think about all the tests that should be written, or they run out of time. The reality is that far fewer tests get written using TAD. Even expert proponents will admit that 70% coverage is about as high as is realistic for TAD code. In contrast, code coverage tools report coverages of 95% and up against the well-written TDD code I've seen.

One more thing that's almost impossible to factor into comparisons: The tests produced by TAD usually have little value in documenting the system. Worse, they usually don't provide the confidence required to refactor the code base at will—which means that the system will degrade in quality more rapidly.

In contrast, well-written TDD tests help an unfamiliar developer more rapidly understand the system. They also provide a much higher confidence for refactoring—which means that the system's quality will degrade less rapidly.

Ultimately, the amount of time saved here and there by TAD pales in comparison to the costs it generates in long-term maintenance and quality of the system. Not to mention that I haven't discussed at all how TDD can help significantly improve the design quality. [In my next article, I'll discuss where testability and design are aligned with one another and where they are not.]

My conclusion: test-after development is a "TAD" too late.

About the Author

Jeff Langr is a veteran software developer celebrating his 25th year of professional software development. He's authored two books and dozens of published articles on software development, including Agile Java: Crafting Code With Test-Driven Development (Prentice Hall) in 2005. You can find out more about Jeff at his site, http://langrsoft.com, or you can contact him via email at jeff at langrsoft dot com.

Page 3 of 3

This article was originally published on September 19, 2007

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date