Testing as a Development Paradigm

Software engineers generally regard testing as a necessary evil. While all developers acknowledge the important role of testing in producing quality software, few admit to relishing the task of testing their own code, or anybody else's for that matter.

XP has turned this perception of the testing process around, breathing new life into the art of software testing. XP has achieved this turnaround by making the writing and running of tests central to the development effort.

The practices of XP covered in Chapter 3.

For many developers, testing prior to the practices of XP was a laborious process. A test case had to be written, test data prepared, and expected results documented before any test could be executed. To make the testing process more palatable, XP seized upon the notion of using automated scripts for all developer-related testing. With XP, developers write code to test code, and writing code is something every engineer enjoys.

The XP approach to testing differs from traditional processes in that the test is written before any implementation code is produced. With the test in place, the next task is to write the minimal amount of code to pass the testno more, no less. Writing the code to pass a test has the test driving the development process, hence the term test-driven development, or test-first development, as it is also known.

This test-driven approach moves the testing process to the forefront of the engineer's attention. The result of this emphasis on testing is tests that prove the implementation meets the requirements and code built to pass these tests.

Test-driven development existed before XP. However, XP has popularized the practice and helped gain widespread acceptance of the merits of test-centric development.

Adopting test-driven development does not require you to embrace the XP process. XP embodies a range of interlocking practices, of which test-driven development is only one. Instead, a test-first approach to development is a valuable addition to any methodology, and its use is actively encouraged as part of the IBM Rational Unified Process (RUP).

Chapter 3 covers the IBM Rational Unified Process.

The Benefits of Test-Driven Development

Following a test-driven approach to development enables the production of a comprehensive suite of automated tests over the course of the project that can be run quickly and easily. By including the testing in the build process, the impact of an application change on the code base can immediately be gauged. The cost of identifying implementation errors at the construction stage is far less than discovering them during a formal testing process by a separate quality assurance team.

Here is a summary of the benefits a test-driven approach can provide:

• Testing requirements are considered early.

• Tests are not omitted, since they are written first.

• The act of writing testing serves to clarify requirements.

• Writing testable code tends to produce better organized software.

• The usability of interfaces is improved because developers are required to work with the interface under test.

• Code changes can be validated immediately as part of the build process.

• The practice of refactoring is supported.

• A higher quality deliverable is provided to the quality assurance team, since unit tests catch defects earlier in the process

A test-driven approach therefore provides a project with the agility it needs to incorporate change into its structure. Changes can be made quickly, accurately, and with impunity on behalf of the software engineer.

Having a comprehensive test suite in place allows invasive techniques such as refactoring to be followed safely. Thus, engineers can undertake sweeping changes to the code base, safe in the knowledge that any errors introduced by such a process will be detected immediately.

The Cost of Test-Driven Development

A test-driven approach to development can significantly improve the quality of software delivered into formal testing. However, while the theory behind test-driven development is attractive, the practice is not without its pitfalls. The writing of code, whether it is for adding functionality or writing tests, still consumes valuable project resources, namely a developer's time. The implementation of an effective automated test suite is not a trivial task. Some of the factors to consider are these:

Complexity.

Each test that forms part of a greater test suite must operate in isolation. It must not exhibit side effects that have an impact on the behavior of other tests within the suite. Achieving this level of isolation between tests is a technical challenge, since the use of common resources, specifically the database, increases coupling between tests.

Test coverage.

A strategy should exist to define the scope and distribution of all tests. A project with a poorly structured test strategy is liable to unit test bloat, whereby developers generate an excessive volume of unit tests with overlapping test coverage. To avoid test duplication, ensure you define your testing strategy early in the project and communicate it to all members of the team.

Maintenance.

As the code base of the application grows, so does the number of automated unit tests. Requirement and design changes are likely to result in the need to update numerous test cases. Although the benefits of the automated test may justify the maintenance overhead of tests, this additional time and cost must be factored into the project schedule.

The build process.

To be truly effective, a regularly scheduled build process should execute all unit tests as part of the build. The process needs to be able to run all unit tests and report test failures accordingly. The effort required to establish and maintain unit tests as part of the build process must be factored into the project's timeline.

Test-driven development can be undertaken effectively with the application of a sound test strategy and the use of a suitable testing framework. In the next sections, we look at the use of the open source testing framework JUnit for building test suites.