A Practical Guide to Testing Object-Oriented Software
| Inheritance provides a mechanism for reuse. Inheritance, as a mechanism for code reuse, was probably a significant factor in making object-oriented programming attractive in the 1980s and early 1990s. However, good object-oriented design calls for inheritance to be used in a very disciplined way that is, in accordance with the substitution principle (see Substitution Principle on page 33). Under that discipline, inheritance is a mechanism for interface reuse instead of code reuse.[1] In our discussions in this chapter, we assume inheritance is used only in accordance with the substitution principle. Under that assumption, the set of test cases identified for a class is valid for a subclass of that class. Additional test cases usually apply to a subclass. With careful analysis of the incremental changes that define a subclass in terms of its superclass, testers can sometimes avoid execution testing of some parts of a subclass because the test cases that apply to the parent just exercise the same code that was inherited intact in the subclass. [1] In our experience, code reuse frequently falls out of interface reuse. During analysis and design, inheritance relationships between classes can be recognized in the following two general ways:
Inheritance relationships can be identified at just about any time during an iterative, incremental development effort. In particular, the specialization relationship can be applied even fairly late in an effort without a large impact on most other program components. This flexibility is one of the big advantages to using inheritance and one of the strengths of object-oriented technologies. It is also a strength of the technology that code for execution-based testing of classes in a hierarchy can be reused. We will show how test plans and test drivers for a derived class can be derived from the tests for its base class. |