Getting started with test-driven development

The right tools will get you on the right track with TDD

I once worked on a project that placed a low priority on process improvement. Everyone complained that building various components of the system took too long, and running regression tests took too long, but no one was willing to change the process. The most common excuse was, "Yes, we know that is a problem, but we are too busy to fix it right now." What amazed those of us working on this project most was the complete lack of value placed on the amount of time it took a developer to complete everyday development tasks.

Compiling and testing are tasks developers perform almost every single day—these tasks should be quick and painless. On this project, however, building just one jar file consisting of a few thousand source files took more than 15 minutes. Running tests involved pulling specific versions of libraries from the CM system, reading directions on multiple Websites, and running five to ten different shell and Perl commands. Once the tests were finished, the developer had to manually decipher test failures hidden in text files with cryptic names. I don't even like to recall how long it took for developers on this project to run the tests.

After a little investigation, the team discovered the build mechanism for that "slow building" library was a poorly written collection of make files. The make files were written such that a separate javac process was forked to compile each source file in the entire library. A simple conversion from the make files to an Ant build file dropped the build time to less than a minute. When we looked into the acceptance tests, we discovered the entire regression test suite consisted of functional tests. By converting the functional tests to unit tests, we were able to cut regression tests that ran for hours down to less than a half hour.

As software engineers, we often deal with performance requirements and end-user acceptance requirements. Why should the development process be any different? Quite frankly, it shouldn't. Development projects should have realistic requirements for how long a build and test cycle should take. Metrics should be collected on a regular basis, so corrective action can be taken as soon as the build and test times exceed requirements.

1 2 Page 1
Page 1 of 2