1. 1 Software Testing and Quality Assurance Lecture 28 – Testing Class Hierarchies

2. 2 Lecture 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.

3. 3 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.

4. 4 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.

5. 5 Subclass test requirements: refinement possibilities Four general ways to define a new derived class that differ 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

6. 6 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.

7. 7 Subclass test requirements: refinement possibilities (cont...)

8. 8 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.

9. 9 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

10. 10 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).

11. 11 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.

12. 12 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.

13. 13 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?

14. 14 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) instances.

15. 15 Testing abstract classes: approach 1 (cont...)

16. 16 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.

17. 17 Testing abstract classes: approach 2 (cont...)

18. 18 Testing abstract classes: approach 3 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.

19. 19 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.

20. 20 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.