Testing Object-Oriented

Applications
 Broadening The View Of Testing
• The construction of object-oriented software
begins with the creation of requirement and
design model.
• Because of the evolutionary nature of OOSE
paradigm, these models begin as relatively
informal representations of system requirements
and evolve into detailed models of classes,
class relationships, system design and
allocation, and object design.
• At each stage, the models can be “tested” in an
attempt to uncover errors prior to their
propagation to the next iteration.
 Testing OOA and OOD Models
• Analysis and design models can not be tested in
the conventional sense, because they can not
be executed.
• Technical reviews can be used to examine
their correctness and consistency.
 Correctness Of OOA And OOD Models

• The notations and syntax used to represent analysis

and design models will be tied to the specific analysis
and design methods that are chosen for the project.
• Hence, syntactic correctness is judged on proper use
of the symbology; each model is reviewed to ensure
that proper modeling conventions have been
maintained.
• During analysis and design, you can assess semantic
correctness based on the model’s conformance to the
real-world problem domain.
• If the model accurately reflects the real world, then it
semantically correct.
• To determine whether the model does reflect real-
world requirements, it should be presented to problem
domain experts who will examine the class-definitions
and hierarchy for omission and ambiguity.
• Class relationships are evaluated to determine
whether they accurately reflect real world object
connections.
Consistency Of Object-Oriented Models
• The consistency of OO models may be judged by
“considering the relationships among entities in the
model. An inconsistent analysis or design model has
representations in one part that are not correctly
reflected in other portions of the model.”
• To assess the consistency, examine each class and
its connections to other classes.
• The class-responsibility-collaboration (CRC)
model or an object-relationship diagram can be used
to facilitate this activity.
• The CRC model is composed of CRC index cards.
Each CRC card lists the class name, its
responsibilities (operations), and its collaborators
(other classes to which it sends messages and on
 which it depends for the accomplishment of its
responsibilities).
• The object-relationship model provides a graphic
representation of the connections between classes.
To evaluate the class model following steps have been
recommended :
1. Revisit the CRC model and the object-relationship
model. : Cross-check to ensure that all collaborations
implied by the requirements model are properly
reflected in the both.
2. Inspect the description of each CRC index card to
determine if a delegated responsibility is part of the
collaborator’s definition. E.g. See the fig. 19.1, for this
collection of classes and collaborations, ask whether a
responsibility (read credit card) is accomplished if
delegated to the named collaborator. That is, does the
class CreditCard have an operation that enables it to
be read? In this case the answer is “yes.” The object-
relationship is traversed to ensure that all such
connections are valid.
3. Invert the connection to ensure that each
collaborator that is asked for service is receiving
requests from a reasonable source. : E.g., if the
CreditCard class receives a request for purchase
amount from the CreditSale class, there would be a
problem. CreditCard does not know the purchase
amount.
4. Using the inverted connections examined in step 3,
determine whether other classes might be required
or whether responsibilities are properly grouped
among the classes.
5. Determine whether widely requested responsibilities
might be combined into a single responsibility. : E.g.,
read credit card and get authorization occur in every
situation. They might be combined into a validate
credit request responsibility that incorporates getting
the credit card number and gaining authorization.
• Steps 1 through 5 are iteratively applied to each
class and through each evaluation of the
requirement model.
• Once the design model is created, conduct the
reviews of the system design and object design.
• The system design depicts the overall product
architecture, the subsystems that compose the
product, the manner in which subsystems are
 allocated to processors, the allocation of the classes
to subsystems, and the design of the user interface.
• The object model represents the details of each
class and the messaging activities that are
necessary to implement collaborations between
classes.
• The system design is reviewed by examining the
object-behavior model and mapping required system
behavior against the subsystem designed to
accomplish this behavior.
• The object model should be tested against the
object-relationship network to ensure that all design
objects contain the necessary attributes and
operations to implement the collaborations defined
for each CRC index card.
 Object- Oriented Testing Strategy

Unit Testing in the OO Context

• Each class and each instance of a class packages

attributes and operations that manipulate these data.
• Because a class can contain a number of different
operations, and a particular operation may exist as a
part of a number of different classes, the operation is
not tested in isolation but rather as a part of a number
of different classes.
 Integration Testing in the OO Context

• There are two different strategies for integration

testing of OO systems :
1) Thread-based testing : integrates the set of classes
required to respond to one input or event for the
system. Each thread is integrated and tested
individually. Regression testing is applied to ensure
that no side effects occur.
2) Use-based testing : begins the construction of the
system by testing those classes that use very few
server classes. After independent classes are
tested, dependent classes are tested.
3) Cluster Testing : A cluster of collaborating classes
is exercised by designing test cases that attempt to
uncover errors in the collaboration.
 Validation Testing in the OO Context

• The validation of OO software focuses on user-

visible actions and user-recognizable outputs from
the system.
• To assist in the derivation of validation tests, the
tester should draw upon use cases that are part of
the requirement model.
• Conventional black box testing methods can be used
to derive validation tests.
 Object Oriented Testing Methods
• The architecture of object-oriented software
results in a series of layered subsystems that
encapsulates collaborating classes.
• It is necessary to test an OO system at a variety
of different levels in an effort to uncover errors
that may occur as classes collaborate with one
another and subsystems communicate across
architectural styles.
• An overall approach to OO test case design :
1 Each test case should be uniquely identified
and explicitly associated with the classes to be
tested.
2 The purpose of the test should be stated.
3 A list of testing steps should be developed for
each test and should contain :
a. A list of specified states for the
class 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 class is tested.
d. A list of external conditions.
e. Supplementary information that will
aid in understanding or implementing the test.
 The Test-Case Design Implications Of OO
Concepts
• As a class evolves through the requirements and
design models, it becomes a target for test-case
design.
• Although encapsulation is an essential design
concept for OO, it can create a minor obstacle
(barrier) when testing.
• Inheritance may present additional challenges
during test-case design.
• Each new usage context requires retesting.
• Multiple inheritance complicates testing further by
increasing the number of contexts for which testing
is required.
• If subclasses instantiated from a superclass are
used within the same problem domain, it is likely
that the set of test cases derived for the super class
can be used when testing the subclass.
• If subclass is used in an entirely different context,
the superclass test cases wil have little applicability
and a new set of tests must be designed.
 Applicability Of Conventional Test Case
Design Methods
• The white box testing methods can be applied to
operations defined for a class.
• Basis path, loop testing, or data flow techniques
can help to ensure that every statement in an
operation has been tested.
• Black-box testing methods are as appropriate for OO
system as they are for systems developed using
conventional software engineering methods.
 Fault-Based Testing
• The object of fault-based testing within OO system is
to design tests that have a high likelihood of
uncovering plausible faults.
• Because the product or system must conform to
customer requirements, preliminary planning
required to perform fault-based testing begins with
the analysis model.
• The tester look 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.
• The effectiveness of these techniques depends on
• Integration testing looks for plausible faults in
operation call or message connections.
• Three types of faults are encountered in this
context : unexpected result, wrong
operation/message used, and incorrect
invocation.
• To determine plausible faults as operations are
invoked, the behavior of the operation must be
examined.
• Integration testing applies to attributes as well as to
operations.
• The behavior of an object are defined by the values
that its attributes are assigned. Testing should
• The focus of integration testing is to determine
whether error exist in the calling code, not the called
code.
• The operation call can be used as a clue, a way to
find test requirements that exercise the calling code.
 Test Cases and The Class Hierarchy
• Inheritance can complicate the testing process.
• For example, A Base class contains operations
inherited() and redefined(). A class Derived
redefines redefined().
• There is a little doubt that Derived :: redefined() has
to be tested because it represent a new design and
new code. But does Derived :: inherited() have to
be retested?
• If Derived :: inherited() calls redefined() and the
behavior of redefined() has changed, Derived ::
inherited() may mishandle the new behavior.
Therefore it needs new tests even though the design
and code have not changed.
• If part of the design and code for inherited() does
not depend on redefined(), that code need not be
retested in the derived class.
• Base :: redefined() and Derived :: redefined() are
two different operations with different specifications
and implementations. Each would have a set of test
requirements derived from the specification and
implementation. Their sets of test requirements will
overlap .
• New tests need to be derived only for those Derived
:: redefined() requirements that are not satisfied by
the Base :: redefined() tests.
 Scenario-Based Test Design
• Fault-based testing misses two main types of errors :
(1) incorrect specification, and (2) interaction
among subsystems.
• When errors associated with an incorrect
specification occur, the product doesn’t do what the
customer wants.
• Errors associated with subsystems interaction
occurs when the behavior of one subsystem creates
circumstances (e.g. events, data flow) that cause
another subsystem to fail.
• Scenario-based testing concentrates on what the
user does, not what the product does. This means
capturing the tasks that the user has to perform and
then applying them and their variants as tests.
• Scenario uncovers interaction errors. To accomplish
this, test cases must be more complex and more
realistic than fault-based tests.
Testing Surface Structure and Deep Structure
• Surface structure refers to the externally
observable structure of an OO program.
• Rather than performing functions, the users of many
OO system may be given objects to manipulate in
some way.
• Whatever the interface, tests are based on user
tasks.
• The best tests are derived when the designer looks
at the system in new and unconventional way.
• Deep structure refers to the internal technical
details of an OO program, that is, the structure that
is understood by examining the design and/or code
 Deep structure testing is designed to exercise
dependencies, behaviors, and communication
mechanism that dependencies, behaviors, and
communication mechanism that have established as
a part of the design model for OO software.
• The requirements and design models are used as
the basis for deep structure testing.
• For example, the UML collaboration diagram or the
deployment model depicts collaboration between
objects abs subsystems that may not be externally
visible.
Testing Methods Applicable At The
Class Level

Random Testing For OO Class

• Random testing is used to exercise a class

during OO testing.
• For example, Bank Application in which Account
class has the following operations : open(),
setup(), deposit(), withdraw(), balance(),
summarize(), creditLimit(), and close().
• Each of these operations may be applied for
Account, but certain constraints (e.g. the
account must be opened before other
 operations can be applied) arte implied by the nature
of the problem.
• The minimum behavioral life history of an instance of
Account includes the following operations :
– Open.setup.deposit.withdraw.close
• This represents the minimum test sequence for
account.
• A variety of different operation sequences can be
generated randomly
– Test case r1 :
Open.setup.deposit.deposit.balance.summarize.
withdraw.close
– Test case r2 :
Open.setup.deposit.withdraw.deposit.balance.creditLi
mit. withdraw.close
• These and other random tests are conducted to
exercise different class instance life histories.
 Partition Testing At The Class Level
• Partition testing is used to exercise a class during
OO testing.
• Partition testing reduces the number of test cases
required to exercise the class. Input and output are
categorized and test cases are designed to exercise
each category.
• But how are the partitioning categories derived?
• State-based partitioning categorizes class
operations based on their ability to change the state
of the class.
• E.g. Account class, state operations include
deposite() and withdraw(), and nonstate operations
include balance(), summarize(), and creditLimit().
• Tests are designed in a way that exercises
operations that change state and those that do not
change state separately.
– Test case p1 :
open.setup.deposit.deposit.withdraw.withdraw.close
– Test case p2 :
open.setup.deposit.summarize.creditLimit.withdraw.cl
ose
• Attribute based partitioning categorizes class
operations based in the attributes that they use.
• E.g., For the class Account, the attributes balance
and creditlimit can be used to define partitions.
Operations are devided into three partitions : (1)
operations that use creditLimit, (2) operations that
modify creditLimit, and (3) operations that do not use
or modify creditLimit.
• Category-based partitioning categorizes class
operations based on the generic function that each
performs.
• E.g., operations in the Account class can be
categorized in initialization operations (open, setup),
computational operations (deposit, withdraw) ,
queries (balance, summarize, creditLimit), and
termination operations (close).
 Interclass Test-Case Design
• Test case design becomes more complicated as
integration of the object-oriented system begins.
At this stage, testing of collaboration between
classes must begin.
• Class collaboration testing can be accomplished
by applying random and partitioning methods,
as well as scenario-based testing and
behavioral testing.
 Multiple Class Testing
• Steps to generate multiple class random test cases:
1) For each client class, use the list of operations to
generate a series of random test sequences. The
operation will send message to other server classes.
2) For each message that is generated, determine the
collaborator class and the corresponding operation
in the server object.
3) For each operation in the server object (that has
been invoked by the messages sent from the client
object), determine the messages that it transmits.
4) For each of the messages, determine the next level
of operations that are invoked and incorporate these
into the test sequences.
• Figure 19.2 Example (explain)
Multiple Class Testing
 Tests Derived From Behavior Models

• The state diagram for a class can be used to help

derive a sequence of tests that will exercise the
dynamic behavior of the class and those classes that
collaborate with it.
• Figure 19.3 Example (explain)
• The state model can be traversed in a “breadth-first”
manner. In this context, breadth-first implies that a
test case exercises a single transition and that when
a new transition is to be tested only previously tested
transitions are used.
Tests Derived From Behavior Models