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

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

What’s Different about Testing OO Programs? Encapsulation Polymorphism Inheritance Development

Unit Testing OO Programs Definition A unit is the smallest possible testable software component, e.g., function, procedure, or module. What’s unit in OO? Method vs. class

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

Class As Unit Purpose Approach 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

Testing Interactions Why test interactions? Intra-class 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.

Describing Test Cases Conventional definition In OO 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 r’s state in the pre-state xi : a list of arguments rpost : the receiver r’s state in the post-state o: expected return value e: expected exception

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); Input Output receiver (r) args (x) receiver (r) return-value exception r.x = 10 x = 20 r.x = 20 none none r.y = 10 r.y = 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

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

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. driver call result unit under test call ack call ack stub1 stubn

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

Separate Test Class Strengths Weaknesses Guideline 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#. Tester CTester C

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

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? C foo() bar() D

Organizing Testing Harness Parallel architecture for class testing (PACT) Use inheritance to organize test cases and test classes Tester CTester C DTester D

Testing Abstract Classes Can you test abstract classes? Approaches