Object Oriented Testing

 object models an entity, thing;

 has a set of attribute values that define a
state of the object
 has set of operations it is capable of
performing to change its attribute values
which may cause changes to attribute
values of other objects.
 object has an identity to uniquely identify it
- distinguish from other objects having the
same attribute values.
 complex interdependency problem
 object state behavior testing problem
 tool support problem
 Encapsulation - information hiding
 Inheritance - from super class - object may
have more than one super class
– methods inherited from a superclass must be
retested in the context of the subclass, because
testing using the context of the superclass may
not include all the cases that may occur in
context of the subclass.
 Polymorphism - take on multiple forms -
attribute have more than one set of values
and an operation may be implemented by
more than one method. Ex - move differs if
chess or checkers
 Dynamic binding - methods that implement
an operation are unknown until run time.
The choice of which implementation to use
when an operation is invoked is determined
at run time according to the types, the
number of arguments, and/or the function-
context of usage.
Object Oriented Testing &
Maintenance Problems
 understanding problem
 complex interdependency problem
 object state behavior testing problem
 tool support problem
 The Understanding Problem:
 Introduced by encapsulation; several member
functions from possibly several object classes are
invoked to achieve an intended functionality.
 Often a member fct of a class in turn invokes
other member fcts, resulting in so-called
invocation chains of member fcts.
 Example shows very long chains - implication of
the invocation chains is that a tester/maintainer
has to understand sequences of member fcts and
the semantics of the classes prior to preparing any
test cases and/or modifying any fct. Look at
table 1.
THE COMPLEX
DEPENDENCY PROBLEM:
 In OO programs that include inheritance,
aggregation, association, template class
instantiation, class nesting, dynamic object
creation, member function invocation,
polymorphism and dynamic binding relationships
complexity is readily found
 InterView 122 classes, 400 inheritance,
aggregation and assoc. relationships - more than
1k member fcts.
Invoc
Chain
length 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

246 305 568 783 742 492 514 482 330 172 82 59 31 10 2
No.
Of
Chains
 It is very difficult to understand a given class
in a large OO program if that class depends
on many other classes
 Without sufficient insight, a tester may not
know where to start in testing an OO library.
 Extremely costly to construct stubs, tester
must understand called fcts, possibly create
and properly initialize certain objects, and
write code to simulate the behaviors and
effects of the called fcts.
 Impossible to predict and equally impossible
to test, all possible uses of a template class
 Difficult to identify and test the effect of
polymorphism and dynamic binding
 Difficult to id change impact in OO
maintenance, since the impact may ripple
throughout the OO program through the
complex dependencies.
STATE BEHAVIOR TESTING
PROBLEM
 Objects have states and state dependent behaviors.
So we need an object state diagram and generate
associated tests.
 Effect of an operation on an object depends of the
state of the object and may change the state of the
object. Thus the combined effect of the
operations must be tested.
 OO state behavior testing can be specification
based or program based. Documentation is either
missing or poor - use a program based approach.
 Derive from the source code the state-
dependent behaviors of the objects and
represent this info in an OSD; generate test
cases and test data from the OSD to test the
program and observe the output.
 THE TOOL SUPPORT
PROBLEM
 CASE tools still in infancy that support OO testing;
 sw testing tedious - preparation, execution, analysis
of tens of thousands of cases and test data sets.
 could use a spec based approach; derived from
specs; required formal specs so tool can derive test
cases - depends on level of detail of formal spec -
observation of authors formal specs rarely used ( at
least in this country)
 tester must manually prepare; does need extensive
tool support
 OOTM ENVIRONMENT
 math defined test model with three diagrams:
– 1) object relation diagram - std stuff of oo model
– 2) block branch diagram - shows control structure
of a member fct; interfaces to other member fcts;
therefore tester knows which data is used and/or
updated and which other fcts are invoked by the
member fct. BBD diagram helps prepare fct test
cases, structural test cases, test harnesses in
member fct unit testing, derive data dependence
across multiple fcts and objects; and display
statement, branch, and path coverage information.
 3) OSD - object state diagram similar to
Statechart - show state behavior of an
object; reduce complexity for each state-
dependent data member of a class; so state
behavior of class is aggregate of the data
 members’ state machines so have hierarchy
of state machines -
 remember - what does a hierarchy do for
us?
 · For maintenance in fixing errors: The
firewall tool automatically identifies changes
and computes the affected classes; displays
the test order for retesting the affected
classes.
 So firewall tool used in two different ways:
– before making actual changes to id impact of
changes; estimate effort in terms of test stubs
and test cases needed to retest the affected
classes
– after making changes, a regression tester can
use the tool to identify the actual changes and
their impact. also compute the optimal test
order to retest the affected classes.
 OOTM OSD consists of hierarchical,
concurrent, communicating state machines.
Supports inheritance and aggregation
features; concurrent because objects viewed
as concurrent processes and communicating
because objects can send and receive
messages from each other.