Object-Oriented Testing

CIS 375
Bruce R. Maxim
UM-Dearborn

1
 OO testing Activities
• Review OOA and OOD models
• Class testing after code is written
• Integration testing within subsystems
• Integration testing as subsystems are
added to the system
• Validation testing based on OOA use-
cases
2
 Correctness of OOA/OOA
Models
• syntactic correctness
– judged by making sure proper modeling
conventions and symbolism were used
• semantic correctness
– checking the model's conformance to the
real world problem domain

3
 Consistency of OOA/OOD
Models - 1
• assess the class-responsibility-collaborator
(CRC) model and object-relationship diagram
• review system design
– examine the object-behavior model to check
mapping of system behavior to subsystems
– review concurrency and task allocation
– examine the use-case scenarios and exercise the
user interface design

4
 Consistency of OOA/OOD
Models - 2
• test object model against the object
relationship network to ensure that all design
object contain necessary attributes and
operations needed to implement the
collaborations defined for each CRC card
• review detailed specifications of algorithms
used to implement operations using
conventional inspection techniques

5
 Class Model Assessment - 1
1. Revisit the CRC model and the object-
relationship model
2. Inspect the description of each CRC card to
determine if a delegated responsibility is part
of the collaborator's definition
3. Invert the connection to ensure that each
collaborator that is asked for service is
receiving requests from a responsible
source
6
 Class Model Assessment - 2
4. Using the inverted connections from step 3,
determine whether
– other classes might be required
– responsibilities are properly grouped among
classes
5. Determine whether widely requested
responsibilities might be combined into a
single responsibility
6. Steps 1 to 5 are applied iteratively to each
class and during OOA model evaluation
7
 OO Unit Testing
• smallest testable unit is the encapsulated
class or object
• similar to system testing of conventional
software
• do not test operations in isolation from one
another
• driven by class operations and state behavior,
not algorithmic detail or data flow across
module interface

8
 OO Integration Testing - 1
• focuses on groups of classes that
collaborate or communicate in some
manner
• integration of operations one at a time
into classes is often meaningless
• regression testing is important as each
thread, cluster, or subsystem is added
to the system

9
 OO Integration Testing - 2
• thread-based testing
– testing all classes required to respond to one
system input or event
• use-based testing
– test independent classes first
– test dependent classes making use of them next
• cluster testing
– groups of collaborating classes are tested for
interaction errors
10
 OO Validation Testing
• focuses on visible user actions and user
recognizable outputs from the system
• validation tests are based on OOA
– use-case scenarios
– object-behavior model
– event flow diagram
• conventional black-box testing methods
can be used to drive the validation tests
11
 OO Test Case Design
• Each test case should be uniquely
identified and be explicitly associated
with a class to be tested
• State the purpose of each test
• List the testing details for each test

12
 OO Test Case Detail
• states to examine for each object involved
• messages and operations to exercised as a
consequence of the test
• exceptions that may occur when the object is
tested
• external conditions needed to be changed for
the test
• supplementary information required to
understand or implement the test

13
 OO Test Design Issues
• White-box testing methods can be
applied to testing the code used to
implement class operations, but not
much else
• Black-box testing methods are
appropriate for testing OO systems

14
 OOP Testing Concerns
• classes may contain operations that are
inherited from super classes
• subclasses may contain operations that
were redefined rather than inherited
• all classes derived from an previously
tested base class need to be thoroughly
tested

15
 Fault-Base Testing
• best reserved for operations and the class
level
• uses the inheritance structure
• tester examines the OOA model and
hypothesizes a set of plausible defects that
may be encountered in operation calls and
message connections and builds appropriate
test cases
• misses incorrect specification and errors in
subsystem interactions
16
 Scenario-Based Testing
• using the user tasks described in the use-
cases and building the test cases from the
tasks and their variants
• uncovers errors that occur when any actor
interacts with the OO software
• concentrates on what the user does, not what
the product does
• you are better off spending more time on
reviewing the use-cases as they are created
and less time on use-case testing
17
 Testing Surface Structure and
Deep Structure
• Testing surface structure
– exercising the structure observable by end-user
– often involves observing and interviewing users as
they manipulate system objects
• Testing deep structure
– exercising internal program structure established
as part of the system and object design
• dependencies
• behaviors
• communications mechanisms
18
 Random Class Testing
• Requires large numbers data
permutations and combinations
• Can be very inefficient
• Using partition testing can reduce the
number of test cases required

19
 Partitioned Class Testing - 1
• state-based partitioning
– tests designed in way so that operations that cause
state changes are tested separately from those
that do not
• attribute-based partitioning
– for each class attribute, operations are classified
according to those that
• use the attribute
• modify the attribute
• do not use or modify the attribute

20
 Partitioned Class Testing - 2
• category-based partitioning
– operations are categorized according to the
function they perform:
• Initialization
• Computation
• Query
• Termination

21
 Interclass Test Case Design
Multiple Class Testing
• for each client class use the list of class operators to
generate random test sequences that send
messages to other server classes
• for each message generated determine the
collaborator class and the corresponding server
object operator
• for each server class operator (invoked by a client
object message) determine the message it transmits
• for each message, determine the next level of
operators that are invoked and incorporate them into
the test sequence

22
 Interclass Test Case Design
Behavior Model Testing
• test cases must cover all states in the state
transition diagram
• breadth first traversal of the state model can
be used (test one transition at a time and only
make use of previously tested transitions
when testing a new transition)
• test cases can also be derived to ensure that
all behaviors for the class have been
adequately exercised
23