Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Test Driven Development is merely one part of a well-balanced diet

Some ranting ahead…           …or just skip to the second paragraph

I’ve never, ever seen any serious minded person claim that TDD is a silver bullet that’s going to stop all defects from getting into your system.  I have heard some people say TDD doesn’t work because it’s impossible to test the user interface, or threading code, or performance.  Even assuming that that’s all true, and it’s not by the way, does that really mean you shouldn’t bother with TDD?  A couple months ago there was a bit of a flame war going on kicked off by Rocky Lhotka’s remarks about TDD on DotNetRocks.  A frequent point of severely flawed logic from the non-TDD camp was “yeah, but TDD doesn’t eliminate the need to test your code.”  Agreed (duh), but in what possible way does this statement invalidate TDD as a practice?  Compiling doesn’t find every possible coding problem, so should we throw that out too?  The last straw was a troll-ish comment on my blog yesterday that went something like “ha ha, you had a bug, guess that TDD stuff doesn’t work after all.  LOL!”  Ignoring the irritating puerile nature of the comment, it’s a myopic point of view.

In Steve McConnell’s Code Complete (v2) book there is an entire chapter devoted to removing defects from code where he compares the effectiveness of a variety of practices in detecting and removing defects from code.  As I recall from the book, no single technique was shown to find all problems, or even most of the defects.  McConnell’s strongly stated advice was to combine as many practices as possible to create a layered defense against defects.  That stack of practices could look like this:

  • JAD sessions – we don’t do nearly enough

  • Whiteboard designs to work through design and architectural issues

  • Simply compiling your code find syntax problems

  • Test Driven Development

  • Integration tests

  • Pair Programming / Code Inspections / Code Reviews

  • Demo screens in progress to users

  • Acceptance Testing with FitNesse, Selenium, etc.  By being able to run automated tests on a developer workstation, we won’t even turn over code to testing until all of the acceptance tests pass. It’s a much, much faster feedback cycle than just throwing the code over the wall to testers.

  • Continuous Integration – finds environmental setup issues, tests the deployment, continuously ensure the code compiles and all of the automated tests run successfully

  • Manual Testing – no you can’t eliminate manual testing, but you should leave that for creative “exploratory” testing

  • User Acceptance Testing – I’ve always thought it was really dumb to leave this strictly for dead last, but…

None of the practices solves every problem, but the combination of the practices is powerful.

A nearly indisputable piece of software lore is that defects are cheaper to fix the sooner they’re detected.  Think about this for a second, how much faster and easier is it for you to fix a problem if you find it when you’re coding initially versus letting a tester find and file a bug report?  How much more bureaucratic crap do you have to go through to fix an official bug versus simply changing the code on your own workstation?

One of the specific areas of value provided by TDD is the rapid feedback on your code.  TDD is more effective than just plain old unit testing.  Real “Test First” TDD gets unit testing injected earlier, and more thoroughly, into the coding lifecycle.  Leaving unit testing for later can easily lead to code that’s difficult to test (I’ve seen this happen far too many times), and it’s difficult to go back over every case.  The problems that are exposed by TDD can be fixed fast and immediately, long before a tester gets a hold of the code or you get stuck in marathon debugging sessions.  If nothing else, you can provide more time for the testers to work through the harder, exploratory testing instead of writing up endless bug report lists for mainline business functionality.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Test Driven Development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://hrboyceiii.blogspot.com Harris

    Ah the chainsaw…reminds me of the early DOS DOOM…

  • jmiller

    “chainsaw in the zombie flick” — I’m going to have to remember that one Eric. Thanks for the comment.

  • Eric Nicholson

    I know I’m preaching to the choir, but don’t forget that defect detection isn’t the only (or even key) benefit to using TDD. Improvements in programmer flow, maintainability, and re-usability make it hard to imagine going back to not using TDD.

    Instead of being the silver bullet in the werewolf flick, TDD is the chainsaw in the zombie flick. It let’s us tear through development with dramatic results, but it’s not the only tool we’re going to need and we still gotta tough it out until daybreak.

  • jmiller

    I had the pleasure of working on a project with Colin a couple years ago. If the balanced diet metaphor is good enough for the pony-tailed one, it’s good enough for me.

  • http://www.kohl.ca/blog Jonathan Kohl

    I like the balanced Diet metaphor for testing. In fact, I just used it a couple of months ago in a “Testing for Programmers” talk I did for a development team. I worked out the balanced diet/testing metaphor with Colin Kershaw before I used it in my presentation. He liked it, and we generated a lot of ideas around it. The audience reacted really positively to it as well. It seems to work.