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 usecases
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

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

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 objectrelationship 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