Chapter 24
Testing Object-Oriented
Applications
Presented by,
R.Bhavani,
AP/CSE/SRC 1
OO
Testing
To adequately test OO systems, three
things must be done:
the definition of testing must be
broadened to include error
discovery techniques applied to
object-oriented analysis and design
models
the strategy for unit and integration
testing must change significantly,
and
the design of test cases must
2
Correctness of OO Models
During analysis and design, semantic correctness
can be asesssed based on the model’s
conformance to the real world problem domain.
If the model accurately reflects the real world
(to a level of detail that is appropriate to the
stage of development at which the model is
reviewed) then it is semantically correct.
To determine whether the model does, in fact,
reflect real world requirements, it should be
presented to problem domain experts who will
examine the class definitions and hierarchy for
omissions and ambiguity.
Class relationships (instance connections) are
evaluated to determine whether they accurately
reflect real-world object connections.because
Use cases can be invaluable in tracking analysis and design models 3
Class Model Consistency
Revisit the CRC model and the
object-relationship model.
Inspect the description of
each CRC index card
to determine if a
delegated responsibility is
part of the collaborator’s
definition.
Invert the connection to
ensure that each collaborator
that is asked for service is
receiving requests from a
reasonable source.
Using the inverted
connections examined in the
preceding step, determine
whether other classes might
be required or whether
responsibilities are properly
grouped among the classes.
Determine whether
widely requested 4
OO Testing Strategies
Unit testing
the concept of the unit changes
the smallest testable unit is the encapsulated class
a single operation can no longer be tested in isolation (the
conventional view of unit testing) but rather, as part of a class
Integration Testing
Thread-based testing integrates the set of classes required to
respond to one input or event for the system
Use-based testing begins the construction of the system by
testing those classes (called independent classes) that use very
few (if any) of server classes. After the independent classes
are tested, the next layer of classes, called dependent classes
(integrates the set of classes that collaborate for one scenario)
Cluster testing defines a cluster of collaborating classes
(determined by examining the CRC and object-relationship
model) is exercised by designing test cases that attempt to
uncover errors in the collaborations. 5
OO Testing Strategies
Validation Testing
Details of class connections disappear
Draw upon use cases that are part of the
requirements model
Conventional black-box testing methods can be
used to derive validation tests
6
OOT
Methods
Berard proposes the following approach:
• Each test case should be uniquely identified and should be
explicitly associated with the class to be tested
•The purpose of the test should be stated
A list of testing steps should be developed for each test
and should contain
a.a list of specified states for the object that is to be
tested
b.a list of messages and operations that will be
exercised as a consequence of the test
c. a list of exceptions that may occur as the object
is tested
d.a list of external conditions (i.e., changes in the
environment external to the software that must
exist in order to properly conduct the test) 7
Testing Methods
Fault-based testing
The tester looks for plausible faults (i.e.,
aspects of the implementation of the system that
may result in defects). To determine whether
these faults exist, test cases are designed to
exercise the design or code.
Class Testing and the Class Hierarchy
Inheritance does not obviate the need for
thorough testing of all derived classes. In fact,
it can actually complicate the testing process.
Scenario-Based Test Design
Scenario-based testing concentrates on what the
user does, not what the product does. This
means capturing the tasks (via use-cases) that
the user has to perform, then applying them and 8
Suggestions to OO testing
• Testing operations outside of the class is generally
unproductive
• If subclass instantiated from a superclass within same
problem domain
• Use test cases of superclass
• If subclass instantiated from entirely different domain
• New set of test case must be designed
Applicability of Conventional Test-Case Design
Methods
• The white-box testing for methods of a class
• Black-box testing for performance of system
OOT Methods: Random
Testing
Random testing
identify operations applicable to a class
define constraints on their use
identify a minimum test sequence
• an operation sequence that defines the
minimum life history of the class (object)
• Ex:
generate a variety of random (but valid) test
sequences
• exercise other (more complex) class
instance life histories
A variety of different operation sequences can be generated randomly as following:
-Test case r1: open•setup•deposit•deposit•balance•summarize•withdraw•close
-Test case r2:
open•setup•deposit•withdraw•deposit•balance•creditLimit•withdraw•close
10
11
OOT Methods: Inter-Class Testing
Inter-class testing
For each client class, use the list of class
operators to generate a series of random
test sequences. The operators will send
messages to other server classes.
For each message that is generated,
determine the collaborator class and the
corresponding operator in the server
object.
For each operator in the server object
(that has been invoked by messages
sent from the client object), determine
the messages that it transmits.
For each of the messages, determine the
next level of operators that are invoked
and incorporate these into the test 12
Interclass test case generation:
(multiple class testing)
