Testing Class Hierarchies

1
Chapter 7

• Testing Class Hierarchies

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
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
Topics Covered

• Inheritance in Object-Oriented Development
• Subclass test requirements
• Refinement possibilities
• Hierarchical, incremental testing
• Organizing testing software
• Testing abstract classes

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
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
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
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
Subclass Test Requirements Refinement
Possibilities (Cont.)
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
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
Summary of Refinements and Effects in
Hierarchical Incremental Testing (HIT)

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 (Ds superclass).

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
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
Organizing Testing Software Another PACT Example
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
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
Testing Abstract Classes Approach 1 (Cont.)
20
Testing Abstract Classes Approach 1 (Cont.)
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
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
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
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
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.