Object-Oriented Testing
February 8, 1998 -- R. A. Volz Chapter 22 1
Triad to test OO systems
Broaden the view of testing
Change strategy for unit and integration
testing
Design test cases to account for the unique
characteristics of OO software
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 of OOA & OOD Models
• Judge by conformance with real world domain
Consistency of OOA & OOD Models
• 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
• Class is the unit of testing
• But, one must test through the class hierarchy
Integration testing in the OO context
• 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.
February 8, 1998 -- R. A. Volz Chapter 22 8
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.
February 8, 1998 -- R. A. Volz Chapter 22 10
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
