Testing Object-Oriented Programs

1
Testing Object-Oriented Programs

• CS 4311
• J. McGregor and D. Sykes. A Practical Guide to
  Testing Object-Oriented
• Software, Addison-Wesley, 2001.
• I. Burnstein. Practical Software Testing,
  Springer-Verlag, 2003.

1
1
2
Outline

• OO testing, why different?
• Class as unit
• Test harness
• Testing class hierarchies

3
Whats Different about Testing OO Programs?

• Encapsulation
• Polymorphism
• Inheritance
• Development

4
Unit Testing OO Programs

• Definition
• A unit is the smallest possible testable software
  component, e.g., function, procedure, or module.
• Whats unit in OO?
• Method vs. class

5
Method As Unit

• Methods tend to be small and less meaningful in
  isolation
• Impossible to test some methods (e.g., private
  methods)
• Overhead to test each method separately

6
Class As Unit

• Purpose
• Test a class as a whole
• Emphasizes interactions among methods
• Approach
• Test critical methods individually
• Test interactions among methods
• Test sequences of methods calls, e.g., pop after
  push

7
Testing Interactions

• Why test interactions?
• An OOP is a collection of objects collaborating
  to solve some problem.
• The correct collaboration (or interaction) is
  critical to the correctness of the program.
• Intra-class interactions
• E.g., pop after push
• Inter-class interactions (integration test)
• Test sequences of messages among collaborating
  objects.
• Can use message sequence diagrams, collaboration
  diagrams, and use case scenarios to generate test
  cases.

8
Describing Test Cases

• Conventional definition
• A pair of inputs and the expected output, ?xi, o?
• In OO
• Need to specify the receiver (often called object
  under test) and its state too, e.g., r in
• r.m(x1, x2, , xn)
• Thus, it is a tuple of ?rpre, xi, rpost, o, e?,
  where
• r is the object under test
• rpre the receiver rs state in the pre-state
• xi a list of arguments
• rpost the receiver rs state in the post-state
• o expected return value
• e expected exception

9
Example

• A test case for testing the method void
  setX(int) of the class Point with the instance
  fields x and y, e.g.,
• Point r new Point(10,10)
• r.setX(20)

10
Constructing Test Cases

• Testing individual methods
• Black-box test and white-box test
• Testing interactions
• Random testing
• State-based approach
• Can use state diagrams to generate sequences of
  method calls
• Testing exceptions
• Design-by-Contract (DBC) vs. defensive design

11
Outline

• OO testing, why different?
• Class as unit
• Test harness
• Testing class hierarchies

12
Test Harness

• A test harness is the auxiliary code developed to
  support testing of units and components,
  consisting of
• Drivers that call the target code, and
• Stubs that represents modules it calls.

call
result
call
call
ack
ack
13
Constructing Test Harness

• Conditionally compiled
• Test code closely maintained with class code
  (e.g., in the same file)
• Hard to reuse (e.g., to test a subclass)
• Requires support for conditional compilation
• As static methods or nested classes
• Test code closely maintained with class code
• Easy to reuse (e.g., by inheritance)
• Need to strip down test code before product
  delivery
• As separate tester class

14
Separate Test Class

• Strengths
• Easy to reuse (e.g., to test a subclass)
• Small and fast production code
• Weaknesses
• Need to create a new tester class
• Need to manage changes carefully
• Guideline
• Use unit testing frameworks such as JUnit for
  Java, CppUnit for C, and NUnit of C.

15
Outline

• OO testing, why different?
• Class as unit
• Test harness
• Testing class hierarchies

16
Testing Class Hierarchies

• If a new class D is added, what methods need to
  be tested?
• Need test bar() of D?
• What about inherited methods, e.g., foo()?
• Can use existing test cases of C?
• What if D adds a new method?

17
Organizing Testing Harness

• Parallel architecture for class testing (PACT)
• Use inheritance to organize test cases and test
  classes

Tester
C
CTester
D
DTester
18
Testing Abstract Classes

• Can you test abstract classes?
• Approaches