OBJECT-ORIENTED TESTING

TESTING OOA AND OOD MODELS

 Analysis and design models cannot be tested in the
conventional sense.
 However, formal technical reviews can be used to
examine the correctness and consistency of both
analysis and design models.
 Correctness of OOA and OOD Models
 Consistency of OOA and OOD Models
Correctness of OOA and OOD Models

 The notation and syntax used to represent

analysis and design models will be tied to the
specific analysis and design method that is
chosen for the project.
 Hence, syntactic correctness is judged on proper
use of the symbology;
 During analysis and design, semantic
correctness must be judged based on the
model’s conformance to the real world problem
domain.
Consistency of OOA and OOD Models

 The consistency of OOA and OOD models may be

judged by “considering the relationships among entities
in the model.
 The CRC model and an object-relationship diagram can
be used to facilitate this activity.
 Each CRC card lists the class name, its responsibilities
(operations), and its collaborators
 The object-relationship model provides a graphic
representation of the connections between classes.
To review 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
OOA model are properly represented.
2. Inspect the description of each CRC index 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 reasonable
source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required and whether
responsibilities are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 through 5 are applied iteratively to each class and through
each evolution of the OOA model.
 Once the OOD model is created, reviews of the system design and
the object design should also be conducted.
 System design depicts the overall
 product architecture
 subsystems that compose the product,
 subsystems allocated to processors,
 design of the user interface.
 The object model presents 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 developed during OOA.
 The object model should be tested against the object-relationship
network
OBJECT-ORIENTED TESTING STRATEGIES

Unit Testing in the OO Context

 When object-oriented software is considered, the concept of
the unit changes.
 This means that each class and each instance of a class
(object) packages attributes (data) and the operations (also
known as methods or services) that manipulate these data.
 Rather than testing an individual module, the smallest
testable unit is the encapsulated class or object. Because a
class can contain a number of different operations and a
particular operation may exist as part of a number of
different classes.
Contd.
Example :
 To illustrate, consider a class hierarchy in which an
operation X is defined for the super-class and is
inherited by a number of subclasses.
 Each subclass uses operation X, but it is applied
within the context of the private attributes and
operations that have been defined for the subclass.
 Unlike unit testing of conventional software,
which focus on the algorithmic detail of a module
and the data that flow across the module
interface, class testing for OO software is driven
by the operations encapsulated by the class and
the state behavior of the class.
Integration Testing in the OO Context

 OO software does not have a hierarchical control

structure. So integrating operations one at a time into a
class is often impossible because of the “direct and
indirect interactions of the components that make up the
class”.
 Two different strategies:
 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.
 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, that use
the independent classes are tested.
 This sequence of testing layers of dependent classes
continues until the entire system is constructed.
 Cluster testing is one step in the integration
testing of OO software. Here, a cluster of
collaborating classes (determined by examining
the CRC and object-relationship model) is
exercised by designing test cases.
Validation Testing in an OO Context
 At the validation or system level, the details of class
connections disappear. Like conventional validation, the
validation of OO software focuses on user-visible actions
and user-recognizable output from the system.
 To assist in the derivation of validation tests, the tester
should draw upon the use-cases that are part of the
analysis model.
 The use-case provides a scenario that has a high
likelihood of uncovered errors in user interaction
requirements.
 Conventional black-box testing methods can be used to
drive validations tests. In addition, test cases may be
derived from the object-behavior model and from event
flow diagram created as part of OOA.
TESTING METHODS APPLICABLE AT THE CLASS LEVEL

Random Testing for OO Classes

 Consider a banking application in which an 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 and closed after all operations
are completed) are implied by the nature of the problem.
 Even with these constraints, there are many
permutations of the operations. Like this way, class
account includes the following operations:
 open•setup•deposit•withdraw•close
This represents the minimum test sequence for account class.
 Similarly,
open•setup•deposit•[deposit|withdraw|
balance|summarize|
creditLimit]n•withdraw•close
 A variety of different operation sequences
can be generated randomly.
For example: Test case r1:
open•setup•deposit•deposit•balance•summariz
e•withdraw•close
Test case r2:
open•setup•deposit•withdraw•deposit•balance•
creditLimit•withdraw•close
Partition Testing at the Class Level
 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.
 Partitioning categories
 State based partitioning
 Attributes based partitioning
 Category-based partitioning
 State based partitioning - class operations based on
their ability to change the state of the class.
For example, account class, state operations include
deposit and withdraw, whereas 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.
 Therefore, Test case p1:
open•setup•deposit•deposit•withdraw•withdraw•close
Test case p2:
open•setup•deposit•summarize•creditLimit•withdraw•close

 Test case p1 changes state, while test case p2 exercises

operations that do not change state (other than those in
the minimum test sequence).
 Attribute-based partitioning - class operations based on
the attributes that they use.
For example, account class, the attributes balance and
creditLimit can be used to define partitions.
 Operations are divided into three partitions:
(1) operations that use creditLimit,
(2) operations that modify creditLimit, and
(3) operations that do not use or modify creditLimit.
 Test sequences are then designed for each partition.
 Category-based partitioning - class operations
based on the generic function that each
performs.
For example, 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).