Object-Oriented

Testing
Contents
 Why OO Testing?
 Impact of OO on Testing
 OO Testing Phases
 Testing OO Systems
 Specific OO Testing Techniques

2
Why OO Testing?

3
Why OO Testing?
 Object-oriented development provides an abstract
way of thinking a problem
 Absent in traditional structured-oriented development

 Techniques and tools for testing a traditional

structured-oriented software are not sufficient to
completely test object-oriented systems
 OO poses some new challenges on testing systems
 Conventional techniques can be used but they probably will
not be enough

4
OO Testing
 OO Testing is Still “Testing”
 We still do
 Unit testing, but we expand the definition of unit
 Component testing to make sure individual
subsystems work correctly
 Integration testing to make sure subsystems work
correctly together
 System testing to verify that requirements are met
 Regression testing to make sure previous functionality
still works after new functionality is added
 But…
5
OO Testing
 Testing strategy changes
 The concept of the unit broadens due to encapsulation

 Integration focuses on classes and their execution across a

thread or in the context of a use case
 e.g. Do your classes work together to allow a user to
complete a task from your scenarios?
 Validation uses conventional black box methods

 Test case design draws on conventional methods, but also

encompasses special features

6
OO Testing
 Although
 Object-oriented analysis and design can lead to a better
system architecture, and
 Object-oriented programming enforces a disciplined coding
style

 Object-Orientation does not

 Shield against programmers’ mistakes or a lack of
understanding of the specification
 Ensure the production of correct programs by itself

 Object-oriented systems still need Testing

7
Impact of OO on Testing

8
Impact of OO on Testing
 Common features of OO development are
complex and, therefore, prone to errors
 Encapsulation
 Information hiding
 Inheritance
 Consistency in abstraction hierarchy
 Multiple inheritance
 Polymorphism
 Dynamic binding
 Exception Handling
9
Encapsulation
 A control access mechanism that determines
the visibility of methods and attributes in a class

 Enforces information hiding

 The interface and implementation of a class may be syntatically
separated
 Avoids undesirable dependencies between client and a server
class
 Only the class interface is visible to the client
 Design decisions and implementation details are hidden

 Encourages program modularity

 Restricts the implication of changes

10
Impact of Encapsulation on
Testing
 Testing requires
 A complete report on the states of an object
 The possibility to change states easily

 Why does encapsulation make OO testing harder?

 Lack of visibility of states
 Besides the behavior encapsulated by an object, it also encapsulates
states
 Difficulty in initializing data items
 Difficulty in calling methods

 Encapsulation does not directly contribute to the introduction of

faults, it may be an obstacle in testing by reducing controllability
and observability

11
Inheritance
 Relationship between classes that allows the definition of a new
(derived) class based on the definition of an existing (base) class

 The derived class can then be refined by modifying or removing

the inherited operations, or by adding new properties

 Single inheritance
 Properties are inherited from a single class
 Strict: the derived class can only be refined by adding new properties
 Subtyping: besides the properties of strict refinement, it allows the
redefinition (overriding) of the inherited properties

 Multiple inheritance
 Properties are inherited from multiple (many) classes

12
Inheritance
 Allows reuse of both specification and implementation
 Shares features present in classes previously defined

 The preexisting classes do not have to be modified or made

aware of the new class

13
Inheritance
 Inheritance can contribute to errors in several ways
 Weakens encapsulation
 Introduces hazards similar to those associated with global data in
conventional languages
 Used inappropriately as
 A powerful macro substitution for convenience
 A model of hierarchy
 Can lead to homograph operations
 Two or more classes with similar name and profile
 When using multiple inheritance

 Leads to side-effects, inconsistencies or incorrect behavior

 Deep and wide inheritance hierarchies can defy comprehension

 Leads to errors and reduction of testability

14
Impact of Inheritance on
Testing
 Opens the issue of “retesting”

 When do we need to retest the superclass?

 When can we assume that the superclass has

already been tested?

 Should operations inherited from ancestor classes

be retested in the context of the descendant
class?
15
Impact of Inheritance on
Testing
 Inheritance can lead to a false conclusion that...
 Aspects already tested in the superclasses do not need to be
retested in the subclasses

 But, in fact, Inheritance defines new context for methods

 Behavior of inherited methods can be changed because of other
methods that are called within the inherited class

 So
 A method which has been tested in a superclass needs a
retesting when it is reused by a subclass
 Even if a method is inherited from a superclass without any
modification (strict inheritance), it has to be retested in the
subclass context

16
Polymorphism
 Ability to refer more than one type of object
using the same name or variable

 Replace explicit compile-time binding and static

type checking by implicit binding and run-time
type checking

 Facilitate compact, elegant and extensible code

 Sometimes constrained by inheritance

17
Polymorphism
 Polymorphism contributes to errors in several ways
 likelihood of misusing a dynamically bound method increases

 The combination of polymorphism and method refinement make

it difficult to understand the behavior of lower level classes

 Object polymorphism with late binding can result in messages

being sent to the wrong class

 Dynamic binding can cause a client class to

 Assume/require a method not provided by the server class
 Misuse an available method

18
Impact of Polymorphism on
Testing
 Brings undecidability to testing
 Dynamic binding: unanticipated bindings

 Each possible binding of a polymorphic

component requires a separate test
 It may be difficult to find/exercise all such bindings

 Erroneous casting (type conversions)

 Can lead to non-easily detectable errors
19
OO Testing Phases

20
Testing OO Software
 Intra-method testing
 Testing individual methods within classes
 Inter-method testing
 Multiple methods within a class are tested in concert
 Intra-class testing
 Testing a single class, usually using sequences of calls to
methods within the class
 Inter-class testing
 More than one class is tested at the same time
(integration)

21
Unit Testing
 We will consider a “Class” as the proper subject of unit testing
 Smallest stand-alone unit for testing
 Instantiation of a single class
 Operations within the class should be tested
 The state behavior of the class should be tested
 Some minimal integration usually required (or stubs)
 Instance variables typically are instances of other classes

 Inheritance and message passing influence how much testing

will be needed

 Intra-method, inter-method and intra-class testing approaches

can be used
22
Unit Testing
 Intra-Method Testing
 Tests a specific method of a class

 Inter-Method Testing
 Methods of the same class may interact to implement a given
functionality
 Kind of integration that should be tested

 Intra-Class Testing
 Tests public method interactions through different sequences of
calls to such methods
 Identifies possible sequences that lead the object to an invalid
state
 Since the user may invoke the public method in many different
orders, the intra-class testing gives one the confidence that different
sequences of calls act correctly

23
Integration Testing
 Integration of classes to create the application system
 Closely tied to the overall development approach
 Inter-Class Testing
 Test public methods: not only those in a single class, but also
those in different classes
 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 sequence.
24
System Testing
 Considers the OO software as a “whole”
 Looks for the errors in the whole system, including
operating system call errors, performance errors, partition
errors...
 Alpha and beta testing can also be used as a complement

 Generally based on black box criteria

 No fundamental difference from procedural and OO
software

25
Procedural vs. Object-Oriented Testing
Testing Phases
Unit Testing
Procedural Testing Object-Oriented Testing

Procedure or Class
Subroutine (Methods)

Integration Testing

Two or More Two or More

Procedures Classes

System Testing

Entire Entire
System System
26
Procedural vs. Object-Oriented Testing

Object-Oriented
Phase Procedural Testing
Testing
Intra-method,
Unit Intra-procedural Inter-method and
Intra-class

Integration Inter-procedural Inter-class

System Entire system Entire system

27
Testing OO Systems

28
Testing OO Systems
 Base Class
 Testing base classes is similar to unit testing of
modules in traditional systems
 Goal: ensure the base classes work correctly in
isolation, before their integration
 Manually prepare a “thorough” test suite
 Apply it to each base class

29
Testing OO Systems
 A complete object test suite requires
 Every operation is executed
 All message parameters and exported attributes are
checked
 Every out-going exception is raised and every in-coming
exception is handled
 Every variable attribute is updated
 Every state is achieved
 Every operation is executed in each state
 Every transition is exercised to test assertions
 Appropriate stress, performance and suspicion tests are
performed
30
Testing OO Systems
 Testing a subclass
 Test the subclass class in conjunction with its
parent
 Determine test cases required for the subclass
 Incrementally update the parent class history (methods
tested, test suite applied, test status) to reflect differences
from the parent class
 Test new attributes or those inherited, affected attributes
 Also test their interactions

31
Testing OO Systems
 Testing a subclass
 New or untested feature in the subclass
 Develop new complete test suite for it
 Prepare intra- and inter-class tests
 Test a new data member by testing the class methods with which
it interacts

 Inherited Features
 Very limited retesting of classes is required
 Integration testing is required if class either
 Interacts with new or redefined variable; or
 Accesses the same instances in the class’s representation as
other methods

32
Testing OO Systems
 Testing a subclass
 Redefined Features
 May be able to reuse black box test cases
 Functionality unchanged
 New white box tests will be required
 Implementation sure to change

33
Specific OO Testing Techniques

34
Specific OO Testing
Techniques
 Traditional
 Boundary
 Partitions
 Decision Tables
 Control Flow
 Data Flow
 State Machines
 Events, Transitions
 UML-Based Model
 Use Case Tests
 Interaction Tests
 Exception Testing (exceptions/handlers)
35
State Machine-based Intra-
class Testing
 Basic idea
 The state of an object is modified by operations
 Methods can be modeled as state transitions
 Test cases are sequences of method calls that
traverse the state machine model

 State machine model can be derived from

specification (functional testing), code
(structural testing), or both
36
Specification Example
 Slot: represents a slot of a computer model
 slots can be bound or unbound
 bound slots are assigned a compatible component
 unbound slots are empty

 Class slot offers the following services:

 Install: slots can be installed on a model as required or
optional
 Bind: slots can be bound to a compatible component
 Unbind: bound slots can be unbound by removing the
bound component
 IsBound: returns the current binding, if bound; otherwise
returns the special value empty
37
Identifying states and
transitions
 Three states
 Not_installed
 Unbound
 Bound

 Four transitions
 install: from Not_installed to Unbound
 bind: from Unbound to Bound
 unbind: ...to Unbound
 isBound: does not change state
38
Deriving an FSM and test
cases
isBound
incorporate
unBind
0 1 2
Not present Unbound Bound
isBound
bind

unBind

 TC-1: incorporate, isBound, bind, isBound

 TC-2: incorporate, unBind, bind, unBind, isBound

39
Testing with State Diagrams
 A statechart (called a “state diagram” in UML) may
be produced as part of a specification or design
 May also be implied by a set of message sequence charts
(interaction diagrams), or other modeling formalisms

 Two options
 Convert (“flatten”) into standard finite-state machine, then
derive test cases
 Use state diagram model directly

40
 Statecharts specification
class model

noModelSelected
method of
super-state or selectModel(model)
class Model
“OR-state” _________________
send modelDB: getModel(modelID,this)
deselectModel()

modelSelected

addComponent(slot, component)
removeComponent(slot)
_________________________ workingConfiguration _________________________
send mopdelDB: findComponent()
send slot:unbind()
send slot:bind()
isLegalConfiguration()
addComponent(slot, component) [legalConfig = true] removeComponent(slot)
_________________________ _________________________
send Component_DB: get_component() send slot:unbind()
send slot:bind
validConfiguration called by
class Model41
From Statecharts to FSMs

noModelSelected

selectModel(model) deselectModel()

addComponent(slot, component) workingConfiguration removeComponent(slot)

deselectModel()
isLegalConfiguration()
addComponent(slot, component) [legalConfig=true] removeComponent(slot)

validConfiguration

42
Statechart based criteria
 In some cases, “flattening” a Statechart to a
finite-state machine may cause “state
explosion”
 Particularly for super-states with “history”
 Alternative: Use the statechart directly
 Simple transition coverage
 execute all transitions of the original Statechart
 incomplete transition coverage of corresponding FSM

43
Inter-class Testing
 The first level of integration testing for object-
oriented software
 Focus on interactions between classes
 Bottom-up integration according to “depends”
relation
 A depends on B: Build and test B, then A
 Start from use/include hierarchy
 Implementation-level parallel to logical “depends” relation
 Class A makes method calls on class B
 Class A objects include references to class B methods
 but only if reference means “is part of”

44
Interactions in Inter-class
Tests
 Proceed bottom-up
 Consider all combinations of interactions
 example: a test case for class Order includes a call to a
method of class Model, and the called method calls a
method of class Slot, exercise all possible relevant states
of the different classes
 problem: combinatorial explosion of cases
 so select a subset of interactions:
 arbitrary or random selection
 plus all significant interaction scenarios that have been
previously identified in design and analysis
 interaction diagrams

45
Interaction diagrams
O:Order C20:Model ChiMod:ModelDB C20Comp:Compoment C20slot:Slots ChiSlot:SlotDB ChiComp:ComponentDB

selectModel()

getmodel(C20)

select()

extract(C20)

addCompoment(HD60)

contains(HD60)

found

isCompatible(HD60)

incompatible

fail

addCompoment(HD20)

contains(HD20)

found

isCompatible(HD20)

compatible

bind

success
46
Summary
 Several features of object-oriented languages
and programs impact testing
 encapsulation, polymorphism, inheritance…
 but only at unit and subsystem levels
 and fundamental principles are still applicable

 Many specific OO testing methods are

developed

47