Section 30.4. Test Infecting for Improvements

30.4. Test Infecting for Improvements

Luckily, it's not necessary to stop all further development and completely revise the software. The best way forward is to slowly make changes over time, in the areas that need to be changed anyway. Luckily, creating and running automated tests can support the restructuring process in two significant ways.

1. A suite of automated tests can be run to determine whether anything is broken during small steps of restructuring of the software. This process can give fast feedback, so that any problems can be dealt with while the recent changes are still in mind.

2. The software often needs to be restructured to support automated testing that gives sufficiently fast feedback, as we discuss later. Surprisingly, such changes naturally lead to more modular and independent code, which is essential for changeability. The code also needs to be organized more around the calculation business rules, as we'll see in Chapter 31.

Erich Gamma calls "test infected" those programmers who use unit tests to drive software development [BG98]. This term has been generalized to the application code itself being "test infected" if it is structured to enable testing. This situation may come about because the code has been written test first, to pass tests that have been written first. Or it may be owing to changes carried out after the code has been written"legacy" code [Fea04]to enable automated testing.

The programmers at RPS were concerned about stopping their developments and code fixing in order to test infect their application in order to introduce unit tests. There's no need for that, and it's rarely realistic, anyway. The way to proceed is in an evolutionary manner, in small steps [Fow99], [Fea04]. Where to start?

Start test infecting where it's most needed: in the areas of change, owing to new functionality or to bugs in that code. Support those changes with Fit tests, to get feedback so that new errors are picked up quickly. As we'll see in Chapter 32, we can support test infecting and other changes by initially testing with Fit, indirectly, through the user interface.

This process may take months or years. Stable parts of the application code may never need to be touched. New developments can be carried out in a test-driven fashion, so that any new code is test infected from the start, as discussed in Chapter 33.