Page 240 -

8.2 Test-driven development 223

the system has actually been executed. Code is tested as it is written so defects
are discovered early in the development process.
2. Regression testing A test suite is developed incrementally as a program is devel-
oped. You can always run regression tests to check that changes to the program
have not introduced new bugs.
3. Simplified debugging When a test fails, it should be obvious where the problem
lies. The newly written code needs to be checked and modified. You do not need
to use debugging tools to locate the problem. Reports of the use of test-driven
development suggest that it is hardly ever necessary to use an automated debug-
ger in test-driven development (Martin, 2007).
4. System documentation The tests themselves act as a form of documentation that
describe what the code should be doing. Reading the tests can make it easier to
understand the code.

One of the most important benefits of test-driven development is that it reduces
the costs of regression testing. Regression testing involves running test sets that have
successfully executed after changes have been made to a system. The regression test
checks that these changes have not introduced new bugs into the system and that the
new code interacts as expected with the existing code. Regression testing is very
expensive and often impractical when a system is manually tested, as the costs in
time and effort are very high. In such situations, you have to try and choose the most
relevant tests to re-run and it is easy to miss important tests.
However, automated testing, which is fundamental to test-first development, dra-
matically reduces the costs of regression testing. Existing tests may be re-run
quickly and cheaply. After making a change to a system in test-first development, all
existing tests must run successfully before any further functionality is added. As a
programmer, you can be confident that the new functionality that you have added has
not caused or revealed problems with existing code.
Test-driven development is of most use in new software development where the
functionality is either implemented in new code or by using well-tested standard
libraries. If you are reusing large code components or legacy systems then you need
to write tests for these systems as a whole. Test-driven development may also be
ineffective with multi-threaded systems. The different threads may be interleaved at
different times in different test runs, and so may produce different results.
If you use test-driven development, you still need a system testing process to val-
idate the system; that is, to check that it meets the requirements of all of the system
stakeholders. System testing also tests performance, reliability, and checks that the
system does not do things that it shouldn’t do, such as produce unwanted outputs,
etc. Andrea (2007) suggests how testing tools can be extended to integrate some
aspects of system testing with TDD.
Test-driven development has proved to be a successful approach for small and
medium-sized projects. Generally, programmers who have adopted this approach are
happy with it and find it a more productive way to develop software (Jeffries and