Object-Oriented Testing

February 8, 1998 -- R. A. Volz

Chapter 22

1

Triad to test OO systems
the view of testing  Change strategy for unit and integration testing  Design test cases to account for the unique characteristics of OO software 
Broaden

February 8, 1998 -- R. A. Volz

Chapter 22

2

Broadening the View of Testing 
Review

OOA & OOD models

‡ Especially useful since same semantic constructs (classes, etc.) appear in analysis, design and impl. 
Can

help avoid

‡ Subclasses added to accommodate unnecessary attributes. ‡ Incorrect or extraneous class relationships ‡ Improper behavior to accommodate extraneous attributes
February 8, 1998 -- R. A. Volz Chapter 22 3

Testing OOA & OOD Models 
Use

CRC index card for review

February 8, 1998 -- R. A. Volz

Chapter 22

4

Testing OOA & OOD Models 
Correctness  Consistency

of OOA & OOD Models of OOA & OOD Models

‡ Judge by conformance with real world domain ‡ Check CRC and object-relationship models for inclusion of all collaborations ‡ Ensure that delegated responsibilities are part of collaborator¶s definition ‡ Ensure that each collaborator is receiving requests from proper source -- inverted conn.
February 8, 1998 -- R. A. Volz Chapter 22 5

Testing OOA & OOD Models 
Consistency

of OOA & OOD Models

‡ Use inverted connection to determine whether other classes or responsibilities are needed. ‡ Determine whether widely requested responsibilities might be combined, e.g., read credit card and get authorization. ‡ Iterate on the above.

February 8, 1998 -- R. A. Volz

Chapter 22

6

OO - Testing Strategies 
Unit

testing in the OO context testing in the OO context

‡ Class is the unit of testing ‡ But, one must test through the class hierarchy 
Integration

‡ Thread-based ‡ Use-based (dependent & independent classes) ‡ Cluster testing -- find errors in collaborations 
Validation

testing in an OO context

‡ System level testing
February 8, 1998 -- R. A. Volz Chapter 22 7

Test Case Design For OO
1. Uniquely identify each test case and associate with the class to be tested. 2. Clearly state the purpose of the test. 3. Develop a list of testing steps:
‡ ‡ ‡ ‡ ‡ List of specified states for object to be tested. List of messages and operations to be exercised. List of exceptions to be tested. List of external conditions. Supplementary information that will aid in understanding or implementing the test.
Chapter 22 8

February 8, 1998 -- R. A. Volz

Test Case Design 
Conventional

test case design is driven by an input-process-output view or by algorithmic detail of individual modules.  OO testing focuses on designing appropriate sequences of operations to exercise the states of a class.
‡ Within object, similar to white box testing.

February 8, 1998 -- R. A. Volz

Chapter 22

9

Test Case Design 
Fault

based testing

‡ Use plausible faults to guide test design ‡ Look for range boundaries, e.g., look for mixups of <, <=, etc. ‡ Look for common operator errors, e.g., mixing up <, > or OR, AND, XOR, +/-, etc. ‡ Use hazard analysis fault trees. 
Scenario

based testing.
Chapter 22 10

February 8, 1998 -- R. A. Volz

Test Case Design 
Random

OO class testing

‡ Randomly generate test sequences of method invocations, e.g., if a banking object has methods, open, deposit, withdraw, balance, summarize, and close, generate random seq. ‡ This should test inappropriate and well as appropriate sequences.

February 8, 1998 -- R. A. Volz

Chapter 22

11

Multiple Class Testing 
For

each client class, generate random test sequences.  For each message, determine collaborators.  For each server operation, determine messages it sends.  For each message, determine the next level of operators.  Compose to form overall test sequence.
February 8, 1998 -- R. A. Volz Chapter 22 12

Multiple Class Testing

February 8, 1998 -- R. A. Volz

Chapter 22

13

Behavior Testing Models 
Ensure

coverage of all states and transitions.

February 8, 1998 -- R. A. Volz

Chapter 22

14