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.

Selecting the right tools

How does one go about implementing a test-driven development (TDD) process? What do you need to practice TDD? The key to TDD is automating the code-compile-test process with the right set of tools! We've all heard the expression, "Use the right tool for the job." This expression definitely holds true for TDD. Without the right tools, implementing and maintaining a TDD process can be time consuming and painful. It's a standard practice for development teams to use common build scripts or make files for compiling source code. A good TDD process takes this practice a step further by implementing common scripts that combine the compile and test steps into a standard development process. So, what are the right tools?

First and foremost is the test framework itself. A test framework supplies a class hierarchy, convenience APIs, and a common language for writing and running repeatable tests. Development teams would probably end up implementing such a framework if they do not use one that is publicly available. Without such a framework, developers would have to re-create common test harnesses and utility classes just to run their own tests. Depending on the requirements of the application you are building, your test and development process may also require additional framework extensions to cover protocols such as HTTP.

The sample application built throughout the remainder of this book is a J2EE-based Football Pool application for automating your favorite office pool. It must run on multiple operating systems and multiple application servers. For now, you only need to be concerned with how the type of application drives requirements for the TDD process. Since the application is a J2EE application, you know your development and test environment must include a J2SE SDK and a J2EE application server. Adding the application-specific elements to your process requirements of an automated code-compile-test process results in the following TDD requirements:

  1. A Java test framework supporting common assertions
  2. A cross-platform scripting tool to start/stop tests and dependent processes
  3. A cross-platform mechanism for building and packaging Java source code
  4. An IDE that supports refactoring
  5. A J2EE application server
  6. A J2SE SDK

Almost every development project goes through a tool analysis process to determine what tools are needed to develop the software. Unfortunately, spending a few chapters comparing tool choices for each of the preceding requirements would severely limit the amount of TDD material I could cover in this book. The following section lists some recommended tools for implementing the preceding TDD requirements. Each tool is briefly described along with a short explanation of why the tool was chosen for the given requirement. I will mention several alternative approaches related to some of these tools, with a sentence or two on why those approaches weren't used here.

1 2 Page 1
Page 1 of 2