Chapter 7 Testing Class Hierarchies. SWE 415 Chapter 7 2 Reading Assignment John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented

Chapter 7

Testing Class Hierarchies

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

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.

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

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.

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.

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

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.

SWE 415 Chapter 7 9

Subclass Test Requirements: Refinement Possibilities (Cont.)

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.


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


Summary of Refinements and Effects in Hierarchical Incremental Testing (HIT)


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


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.


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.


Organizing Testing Software: Another PACT Example


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?


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.


Testing Abstract Classes: Approach 1 (Cont.)


Testing Abstract Classes: Approach 1 (Cont.)


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.


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.


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.


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.


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.

Documents

Chapter 7 Testing Class Hierarchies. SWE 415 Chapter 7 2 Reading Assignment John McGregor and David A. Sykes, A Practical Guide to Testing Object-Oriented