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:
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:
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.