Organizing Testing Software

The relationship between test requirements for a subclass, such as MovableSprite, and the test requirements for a base class supports an inheritance relationship between Tester classes that we described in Chapter 5. In other words, we can develop a test driver for a subclass D by deriving its Tester class from the Tester class for C, D's superclass. Figure 7.7 shows the structure, which we refer to as the parallel architecture for class testing (PACT) [McGr97]. The structure determined by PACT for the Sprite class hierarchy is shown in Figure 7.8.

Figure 7.7. Parallel architecture for class testing (PACT)

Figure 7.8. PACT structure for the Sprite hierarchy

Using PACT reduces the effort needed to test a new subclass. The organization of test case methods and test script methods we described in the previous two chapters facilitates the testing of subclasses by letting us invoke them in Tester subclasses. If an operation is refined in a subclass, then the corresponding tester methods can be reused in the subclass and refined as necessary to reflect new preconditions, postconditions, and/or implementation. Test case methods and test script methods for new operations can be added in the subclass Tester. PACT presents a clean organization and is easy to implement.

At the root of the PACT hierarchy is the abstract class Tester that we described in Chapter 5. Each subclass of Tester must provide implementations for the abstract operations and could override methods for any of the other operations. Each subclass has the same basic organization presented in Chapter 5: test case methods, a method corresponding to each constructor to create an object under test, and a method to create an object under test in some specified state. These classes are straightforward to implement once the test cases have been identified.