1. Chapter 7 Testing Class Hierarchies

2. SWE 415 Chapter 7 2 Reading Assignment  John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001, ISBN: 0-201-325640. Chapter 7: Testing Class Hierarchies

3. SWE 415 Chapter 7 3 Objectives To know what must be tested in code that is inherited. To learn how to encapsulate the test cases for a specific class using PACT. To learn what testing is possible for abstract classes.

4. SWE 415 Chapter 7 4 Topics Covered Inheritance in Object-Oriented Development Subclass test requirements  Refinement possibilities  Hierarchical, incremental testing Organizing testing software Testing abstract classes

5. SWE 415 Chapter 7 5 Inheritance in Object-Oriented Development Good object-oriented design requires for a very disciplined use of inheritance with substitution principle. Assumption: inheritance has been used in accordance with the substitution principle.  Under this 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.

6. SWE 415 Chapter 7 6 Subclass Test Requirements Testing a class in an inheritance hierarchy is generally more straightforward when approached from the top down.  In testing the top classes in the hierarchy, we can address the common interface and code and then specialize the test driver code for each subclass.

7. SWE 415 Chapter 7 7 Subclass Test Requirements: Refinement Possibilities Four general ways to define a new derived class that differs from its parent class:  Add a new operation in the interface of the derived class and possibly a new method to implement each new operation.  Change the specification or implementation of an operation from the superclass Change in the subclass the specification for an operation declared in the parent class. Override in the subclass a method in the parent class.  Add one or more instance variables to the subclass to implement more states and/or attributes.  Change the class invariant in the subclass

8. SWE 415 Chapter 7 8 Subclass Test Requirements: Refinement Possibilities (Cont.) All the test cases that apply for the parent class should apply for the subclass. We need new additional test cases for the new operations.

9. SWE 415 Chapter 7 9 Subclass Test Requirements: Refinement Possibilities (Cont.)

10. SWE 415 Chapter 7 10 Subclass Test Requirements : Hierarchical, Incremental Testing (HIT) The incremental changes between class C and its derived class D can be used to guide the identification of what needs to be tested in D. Inherited test cases: test cases for a subclass that were identified for testing its base class.

11. SWE 415 Chapter 7 11 Subclass Test Requirements : Hierarchical, Incremental Testing (Cont.) Use analysis to determine for a subclass  What test cases need to be added  What inherited test cases need to be run  What inherited test cases do not need to be run

12. SWE 415 Chapter 7 12 Summary of Refinements and Effects in Hierarchical Incremental Testing (HIT)

13. SWE 415 Chapter 7 13 Organizing Testing Software Parallel architecture for class testing (PACT): We can develop a test driver for a subclass D by deriving its Tester class from the tester class of C (D’s superclass).

14. SWE 415 Chapter 7 14 Organizing Testing Software (Cont.) PACT reduces the effort needed to test a new subclass. 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, postcondition, and/or implementation. The root of the PACT hierarchy is the abstract class Tester.

15. SWE 415 Chapter 7 15 Organizing Testing Software (Cont.) 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 following organization:  Test case methods  A method corresponding to each constructor to create an object under test.  A method to create an object under test in some specified state.

16. SWE 415 Chapter 7 16 Organizing Testing Software: Another PACT Example

17. SWE 415 Chapter 7 17 Testing Abstract Classes Execution-based testing of a class requires that an instance of the class be constructed We can not create an instance of abstract class, so how to test an abstract class?

18. SWE 415 Chapter 7 18 Testing Abstract Classes: Approach 1 A concrete subclass of the abstract class is defined solely for the purpose of testing:  Disadvantage: the implementation of the abstract method cannot be propagated easily to abstract subclass without using multiple (repeated) inheritance.

19. SWE 415 Chapter 7 19 Testing Abstract Classes: Approach 1 (Cont.)

20. SWE 415 Chapter 7 20 Testing Abstract Classes: Approach 1 (Cont.)

21. SWE 415 Chapter 7 21 Testing Abstract Classes: Approach 2 Test an abstract class as part of testing the first concrete descendent  Advantage: no need develop extra classes for testing  Disadvantage: increase the complexity in testing the concrete class.

22. SWE 415 Chapter 7 22 Testing Abstract Classes: Approach 3 Develop direct implementation of a concrete version of the abstract class for testing (write the source code for a class so that it can easily be complied as an abstract or concrete class).  The resulting code is complex and hard to read.

23. SWE 415 Chapter 7 23 Testing Abstract Classes: Approach 4 Test an abstract class using guided inspection instead of execution-based testing  Abstract class provides a little or no implementation for the abstract operations.  Public interfaces for abstract classes stabilize quickly.  Concrete operations can easily be tested by inspection  But constructors and destructors are more complicated to be tested by inspection only.

24. SWE 415 Chapter 7 24 Testing Abstract Classes: Recommendations Do execution-based testing. PACT offers advantages for testing families of classes. Use approach 2:  Straightforward  Requires relatively little additional coding effort for implementing testers.  Easily perform regression testing.

25. SWE 415 Chapter 7 25 Key Points Inheritance provides a mechanism for interface and code reuse. Four ways to define a new derived class that differ from its parent class. Hierarchical, incremental testing (HIT): The incremental changes between class C and its derived class D can be used to guide the identification of what needs to be tested in D. Organizing testing software:  Parallel architecture for class testing (PACT). Four approaches to test abstract classes.