Test before you leap into development

Programmer and author Dave Johnson shared an anecdote on his Weblog last year about what happened when his 5-year-old son walked up behind him while he was coding. "He saw the JUnit green bar on the screen," Johnson reports, "and said 'Dad, you did good.' " There's more to this touching father-and-son moment than meets the eye. The idea that software development can proceed by tackling a sequence of small tasks -- the successful completion of which is evident even to a child -- is fueling a groundswell of interest in the so-called "xUnit" testing frameworks (see sidebar) and in a companion work style called "test first" or "test driven."

Practitioners of TDD (test-driven development) typically align themselves with one or another of the "agile" methodologies -- most notably, XP (eXtreme Programming) -- and use software tests in an unconventional way. Historically, IT has thought that the people who write code can't, or shouldn't, be responsible for testing it. In many ways that's still a good rule of thumb. QA (quality-assurance) testers will always be needed to find problems -- poor user interfaces, slow response under load, or incorrectness -- that programmers have overlooked. TDD doesn't put them out of a job.

"If you're the head of QA and you hear that your developers are working test-first," says Ward Cunningham , an independent consultant pioneering the approach, "you should think, 'Good for them -- now we can focus on the truly diabolical tests instead of worrying about these dead-on-arrival problems,' " (see "XP pioneer stumps for test-first programming").

TDD solves a different set of problems. It does so by proposing that before you write any nontrivial piece of production code, you write tests that the code will at first fail, and then when written correctly, will pass. TDD advocates say this approach has two major benefits.

First, because the tests embody specific uses of the yet-unwritten software, they will help tease out the design of the software, complementary to other techniques such as requirements specification and modeling. Second, the tests create a safety net, enabling the programmer to engage in the risky but necessary practice of refactoring -- continuously reorganizing the code -- without fear of breakage. One of XP's tenets is that change is the only constant. As the business environment evolves, so do the requirements it imposes on software. Although software is in theory perfectly malleable, in practice we are often afraid to change it. TDD seeks to reduce that fear by controlling the risk associated with change.

Serious practitioners of TDD write a lot of tests. Kent Beck, author of Test Driven Development: By Example, notes that one project done in the TDD style amounted to 250,000 lines of production code and an equal number of lines of test code. Others confirm that this one-to-one ratio is typical. Can this really be economical?