Good Object Oriented Testing Slides

Testing Object-Oriented Software
Part One
Object-Oriented Principles
from a testing perspective
Test early, test often, test enough.
Software Engineering of Standalone Programs
University of Colorado
January 20, 2002
ECEN5033 - OO Testing University of Colorado
Primary reference
A Practical Guide to Testing Object-Oriented
Software
John McGregor and David A. Sykes
Addison Wesley Object Technology Series, 2001
ISBN 0-201-32564-0
January 20, 2002
What is software testing?

The evaluation of the work products created during a
software development effort
Done throughout development effort
Applied to all development products (models) before
as well as after code is written
More specifically
The process of uncovering evidence of defects
Since a defect can be introduced at any phase,
testing efforts find defects in all phases
Testing is not the debugging, isolation, or repair of
bugs
January 20, 2002
What is software?
The instruction codes and data necessary to accomplish
some task on a computer or microprocessor
All representations of those instructions and data
Analogy
Architects and builders can examine blueprints to
spot problems
We can examine analysis and design models before
the code is written with a form of execution.
January 20, 2002
Assumptions
Development process is incremental with iterations
within each increment
Models are expressed in UML
Software design in accordance with good design
principles
inheritance
data hiding
abstraction
low coupling
high cohesion
January 20, 2002
Testing vs. Quality Assurance

Quality Assurance
Responsible for test plans and system testing
Monitor testing during development
Keep statistics
Testing is a necessary but insufficient part of a QA process
QA addresses activities designed to
prevent defects
remove defects
Testing helps in identifying problems and failures
Testing helps QA by identifying them early in dev.
January 20, 2002
Whats special about testing OO software?

Features such as class inheritance and interfaces
support polymorphism in which code manipulates
objects without their exact class being known
Testers must ensure the code works no matter what
the exact class of such objects might be.
Features that support data hiding complicate testing
because operations must be added to a class interface
(by the developer) just to support testing
January 20, 2002
OO Testing Is Still Testing

We still do
unit testing but we change the definition of unit
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
January 20, 2002
OO Testing Is Not Just Old Style Testing

Fundamental aspect of OO software
OO Software is designed as a set of objects that
essentially model a problem and then collaborate to
effect a solution
While the solution may change over time, the structure
and components of the problem do not change as
frequently
a program structured from the problem is more
adaptable to changes later
components derived from the problem can be reused
in development of other programs to solve related
problems
January 20, 2002
Benefit
Many analysis models map straightforwardly to design
models which, in turn, map to code
Start testing during analysis
Refine the same tests for design
Refine those tests for code
January 20, 2002
10
Advantages of testing
analysis and design models
Test cases can be identified earlier in the process, even
while determining requirements
Early test cases help analysts and designers to
better understand and express requirements
ensure that specified requirements are testable
Bugs can be found early saving time and money
Test cases can be reviewed for correctness early in the
project
If test cases are applied to models early,
misunderstandings of requirements on the part of
testers can be corrected early
January 20, 2002
11
Avoid the bugging phase

In other words, model testing helps to ensure that
testers and developers have a consistent understanding
of the system requirements early in the project.
However, code testing is still important
January 20, 2002
12
Categories of OO Testing
Model testing
Class testing instead of unit testing
Class interaction testing instead of integration testing
System and subsystem testing
Acceptance testing
Self-testing
Should you try to apply all of these? Probably not if
you want to be taken seriously and be employed.
You should learn to recognize approaches and
techniques that will apply to your project in a useful
and affordable way.
January 20, 2002
13
Testing perspective
Skeptical, objective, thorough, systematic
Look at any development product and question its
validity
Attitude that should be held by a developer as well as a
full-time tester
To ensure
a. the software will do what it is supposed to do
b. the software will not do what it is not supposed to
do
Ensuring a. does not automatically ensure b.
January 20, 2002
14
Object
An operational entity that encapsulates both specific
data values and the code that manipulates those values.
Provides the mechanisms needed to
receive messages
dispatch methods
return results
associates instance attributes with methods
January 20, 2002
15
Objects from a testing perspective

Encapsulates the complete definition of the object is
easy to identify, easy to pass around, easy to manipulate
Hides information can make changes to the object hard
to observe which makes checking test results difficult
Has a state that persists for its life. This state can become
inconsistent and can be the source of incorrect behavior
Has a lifetime can be examined during its lifetime to
check if it is in the right state based on its lifetime.
Common source of failures construction of an object
too late or destruction of it too early
January 20, 2002
16
Message
Message a request that an operation be performed by
some object.
can include actual parameters used to perform that
operation
receiver can return a value
OO program is a community of objects that collaborate
to solve a problem.
This is achieved by sending messages to one another
Can result in a return value
Can result in an exception from receiver to sender
January 20, 2002
17
Messages from a testing perspective

A message
has a sender who determines when to send and may
make an incorrect decision about this
has a receiver
may not be ready for the specific msg it receives
may not take the correct action if msg is unexpected
may include actual parameters

used by or updated by the receiver
objects passed as parameters must
be in correct states before and after the message is
processed
implement the interfaces expected by the receiver
January 20, 2002
18
Those issues are the primary focus of

interaction testing
January 20, 2002
19
Interface
Aggregation of behavioral declarations
Example: a set of behaviors related to being a moving
item on a screen such as the ball in (the old game of)
Pong
Building block for specifications
A specification is the total set of public behaviors for a
class.
-------------- Java: has a syntactic construct interface; doesnt allow
declaration of any state variables
C++: declare an abstract base class with only public, pure
virtual methods
January 20, 2002
20
Interfaces from a testing perspective

Interface encapsulates operation specifications which
build the specifications of larger groupings such as
classes
If it contains behaviors that do not belong with the
other behaviors, implementations of the interface
will have unsatisfactory designs
Interface has relationships with other interfaces and
classes.
may be specified as the parameter type for a
behavior to allow any implementer of that interface
to be passed as a parameter
Interface describes a set of behavior declarations
whether or not we use the interface syntax
January 20, 2002
21
Class
Set of objects that share a common conceptual basis.
Class definition says what members (objects) of the set
look like, what they have in common.
Objects form the basic elements for executing OO
programs
Classes are the basic elements for defining OO
programs
Any concept to be represented in a program must
first be defined in a class.
Then objects defined by that class are created
(instantiation) and are called instances.
object = instance
January 20, 2002
22
Class as object
Note:
OO languages usually allow a class to be an object itself
and can have operations and attributes defined for it
In C++ and Java, operations and data values associated
with a class are identified by the keyword static and these
operations are called static operations
Public static operations in a class specification mean
the class itself is an object that can be messaged
we must treat the class as an object and create tests for
the class as well as for its instances
Scary thought: non-constant static data associated with a
class can affect the behavior of the instances (yikes!)
January 20, 2002
23
ClassA
SubClassA2
SubClassA1
January 20, 2002
24
Operations
A class specification includes a specification for each
of the operations that can be performed by each of its
instances
An operation is an action that can be applied to an
object to obtain a certain effect.
Accessor (inspector) operations provide
information about the object but do not change the
object
Modifier (mutator) operations change the state of
the object by setting one or more attributes to have
new values (perhaps not every time)
Accessors are tested differently than modifiers.
January 20, 2002
25
Two special operations

Constructor a class object operation used to create a
new object
includes initializing a new instance when it comes
into existence
Destructor an instance object operation used to
perform any processing needed just prior to the end of
the objects lifetime
Differ from accessors & modifiers
invoked implicitly as a result of the birth and death
of objects
January 20, 2002
26
What do we expect of a class specification?

A description of what a class represents.
Its either a concept in the problem being solved or
in the solution to that problem
Some meaning and constraints to be associated with
each of the operations defined in the class specification
So ... each operation should have a specification that
describes what it does, including its preconditions
and invariants
January 20, 2002
27
Reminder
Preconditions
Conditions that must hold before the operation can be
performed.
Post conditions
Conditions that must hold after the operation is
performed.
Invariants
Conditions that must always hold within the lifetime of
the object
An operations method may violate invariants during
execution but it must hold again by completion.
January 20, 2002
28
Preconditions
Usually stated in terms of one or more of the
following:
attributes of the object containing the operation
attributes of any actual parameters in the message
requesting that an operation be performed
January 20, 2002
29
Post conditions
Usually stated in terms of one or more of the
following:
attributes of the object containing the operation
attributes of any actual parameters in the message
requesting that the operation be performed
the value of any reply
the exceptions that might be raised
January 20, 2002
30
Invariants
A class invariant describes a set of operating
boundaries for an instance of a class
It is possible to define interface invariants and
operational invariants
A class invariant can be treated as an implied post
condition for EACH operation in the class
Usually stated in terms of
attributes of an object
states of an object
January 20, 2002
31
Behavior of the instances of a class

The aggregate of the specifications of all of the
operations in a class provides
part of the description of the behavior of its
instances
Behavior
difficult to infer from operation specifications alone
typically designed and represented at a higher form
of abstraction
defining a set of states for an instance
describing how various operations effect transitions from
state to state
January 20, 2002
32
To write a specification for an operation

To define the interface between the receiver and the
sender
Contract approach emphasizes preconditions but
has simpler post conditions
Defensive programming approach -- emphasizes
post conditions but has simpler preconditions
January 20, 2002
33
Contract approach to class design from a

testing perspective
Preconditions specify obligation of the sender
If met, receiver is obligated to meet the requirements
set form in the post conditions and class invariant
Care must be taken in the design of the class interface
to ensure that
the preconditions are sufficient to allow a receiver to
meet the post conditions
a sender can determine whether all preconditions are
met before sending a message
post conditions address all possible outcomes of an
operation, assuming preconditions were met
January 20, 2002
34
Defensive approach to class design from a

testing perspective
Interface defined primarily in terms of the receiver and any
assumptions it makes on its own state and the values of any
inputs (arguments or global data) at the time of the request.
Operation typically returns some indication re status of the
result of the request (success or failure),
traditionally as a return code associating a value with each
possible outcome
can provide to sender an object that encapsulates the status of
the request
Identify garbage in and eliminate garbage out by checking
for improper values coming in and reporting the status of
processing the request to the sender
January 20, 2002
35
What does this mean for tester?

The approach used in an interface determines the types
of testing that need to be done.
Contract approach
simplifies class testing
complicates interaction testing must ensure any
sender meets the preconditions
Defensive approach
complicates class testing test cases must address
all possible outcomes
complicates interaction testing must ensure all
possible outcomes are produced and that they are
properly handled by the sender
January 20, 2002
36
During design and design inspections of a

class how maintain testing perspective?
Review the preconditions and post conditions for
testability
Are the constraints clearly stated?
Does the specification include the means by which one
can check preconditions? (the sender does not want to
be an expert on the receiver; receiver should explain
how to check for the preconditions)
January 20, 2002
37
Class implementation
Describes how an object represents its attributes and carries
out its operations. It is made of several components:
A set of data values stored in data members (aka instance
variables or variables) some or all of the values associated
with the attributes of an object.
A set of methods (aka member functions) code used to
implement an algorithm to accomplish an operation
declared in the public or private class specification.
A set of constructors to initialize a new instance.
A destructor to handle any processing associated with
destruction of an instance
A set of private operations in a private interface provide
support for the implementation of public operations.
January 20, 2002
38
Importance of class testing

Classes define the building blocks for OO programs
A class is an abstraction of the commonalities among
its instances therefore, the testing process must
ensure that a representative sample of members are
selected for testing.
January 20, 2002
39
Classes from a testing perspective

A class specification contains operations to construct
instances. They may not properly initialize the
attributes of new instances.
Class relies on collaboration to define its behaviors and
attributes. The other classes may be implemented
incorrectly and contribute to failure of the class that
relies on them.
A class implementation satisfies its specification
does not mean the specification is correct.
Might not support all required operations; may perform
them incorrectly.
Might not provide a way for a precondition to be
checked by a sender before sending a message
January 20, 2002
40
Inheritance
Relationship between classes that allows the definition
of a new class based on the definition of an existing
class.
allows reuse of both specification & implementation
important advantage: the preexisting class does not
have to be modified or made aware of the new class
New class is called subclass or derived class
Parent class is called superclass or base class
Each class (except the root) has one or more ancestors;
the chain of ancestors up to the root is called
inheritance hierarchy
January 20, 2002
41
Good OO Design Use of Inheritance

Used only to implement an is-a or is-a-kind-of
relationship
Best use: with respect to specifications and not
implementation inclusion polymorphism, for
example (more on that in a moment)
January 20, 2002
42
Inheritance from a testing perspective

Provides a mechanism by which bugs can be
propagated from a class to each of its descendants
Important reason to test classes as they are
developed to eliminate fault propagation
Provides a mechanism by which we can reuse test
cases.
subclass inherits part of its specification and
implementation from its superclass, potentially can
reuse test cases from superclass to subclass
Models an is a kind of relationship
Use of inheritance solely for code reuse will
probably lead to maintenance difficulties
Common mistake in OO development
January 20, 2002
43
Inheritance models is-a-kind-of relationship

If D is a subclass of C, then D is a kind of C
If so, an instance of D can be used whenever an instance
of C is expected
To work, the behavior of D must somehow conform to
that which is associated with C
Behavior of a class
observable states of an instance
the semantics associated with the operations defined
for an instance of that class
Behavior of a subclass incremental changes to the
observable states and operations defined by its superclass
January 20, 2002
44
Substitution Principle
Only the following changes are allowed in defining the
behavior associated with a new subclass:
Preconditions for each operation must be the same
or weaker less constraining than those of the
superclass
Post conditions for each operation must be the same
or stronger do at least as much as defined by the
superclass
Class invariant must be the same or stronger; add
more constraints
January 20, 2002
45
Substitution Principle of Inheritance

Developers must enforce (in inspections, if not before) the
constraints of this principle on behavior changes
Observable states and all transitions between them
associated with the superclass must be preserved by the
subclass
The subclass may add transitions between these states
The subclass may add observable states as long as each
is either concurrent or a substate of an existing state
In other words, dont use inheritance because you are too
lazy to specify a class that is similar but is-not-a-kind-of
January 20, 2002
46
Polymorphism
Ability to treat an object as belonging to more than one
type.
Not necessarily the safest approach to programming
Supports designs that are flexible
Inclusion polymorphism is the occurrence of different
forms in the same class
Can substitute an object whose specification
matches another objects specification for the latter
object in a request for an operation
i.e., a sender can use an object as a parameter based
on its implementation of an interface rather than its
full class
January 20, 2002
47
A class is a set of objects that share a common

conceptual basis.
This definition is influenced primarily by associating
inheritance and inclusion polymorphism
The class at the root (top of tree graph) establishes a
common conceptual basis for all objects in the set.
A descendant refines the behavior established by the
root class and intermediate ancestors
Objects in the descendant class are still in the set of
objects in the root class a subset of each of the sets
defined by its ancestors
January 20, 2002
48
Two perspectives of sets representing classes

both are useful during testing
Class perspective each set contains all instances,
maybe an infinite number; most easily represented with
Venn diagrams
Executing programs perspective each set is drawn
with one element per instance in existence.
January 20, 2002
49
A Matter of Perspective
When a class is to be tested
outside context of any application program, we test
it by selecting arbitrary instances using the class
perspective
in context of an executing application program or in
context of object persistence, we use the other
perspective
ensure size of set is correct
ensure elements correspond to appropriate objects
in the problem or solution
January 20, 2002
50
Inclusion polymorphism powerful capability

Can perform all design and programming to interfaces
without regard to exact class of the object sent to a
message to perform an operation
Takes design and programming to a higher level of
abstraction
Can define classes for which no instances exist but for
which its subclasses have instances
An abstract class purpose is to define an interface
that is supported by all of its descendants
Exploits polymorphism during design to extend a
system incrementally by adding classes instead of
modifying existing ones
January 20, 2002
51
Inclusion polymorphism from a testing perspective

A polymorphic reference hides the actual class of a referent
(referent is the thing being referred to).
All referents are manipulated through their common
interface.
Allows systems to be extended by adding classes rather than
modifying existing ones unanticipated interactions can
occur in the extensions
Allows any operation to have 1 or more parameters of a
polymorphic reference increases the number of possible
kinds of actual parameters that should be tested
Allows operation to specify replies that are polymorphic
references actual class of referent could be unanticipated
by the sender
January 20, 2002
52
Impact of this dynamic nature of OO

Puts more importance on testing a representative
sample of runtime configurations
Static analyses provide potential interactions that might
occur
Only runtime configuration illustrates what actually
happens
In the McGregor & Sykes book, they explain a
statistical technique to assist in determining which
configurations will expose the most faults for the least
cost of resources
January 20, 2002
53
Each subclass must be a subtype

That is, each specification for the subclass must fully meet all
specifications of its direct ancestor
This is an enforceable design requirement when these rules are
applied (refers to diagram on next slide):
The tryit method in A, the sender, satisfies the preconditions of
the doIt operation of B before tryit calls doIt. If an instance of C
or D is to be substituted, the preconditions for Cs doIt or Ds
doIt must not add any new conditions to those for Bs doIt.
(Why?)
If an instance of C or D is to be substituted when As tryit sends
a message to Bs doIt, the post conditions on Bs doIt must still
be true although C or D can add additional post conditions.
Similarly for the invariant for B must still be true in instances
of C and D although additional invariants may be added.
January 20, 2002
54
Design solution with inclusion polymorphism

A
tryit(B b)
tryit(B b) {
b.doIt( );}
January 20, 2002
B
doIt( ) {...}
C
doIt( ) {...}
D
doIt( ) {...}
55
Parametric Polymorphism
The capability to define a type in terms of one or more
parameters rather like a macro
C++ provides this with the concept of templates
a compile-time ability to instantiate a new class
new because an actual parameter is provided for the
formal parameter (at compile-time) in the definition
Instances of the new class can then also be created
Used a lot in the C++ Standard Template Library
Almost looks like a kind of inheritance but it isnt
If the template works for one instantiation, no
guarantee it will work for another
January 20, 2002
56
Parametric Polymorphism
Need to inspect details of the template code to
understand what it will do with various parameters
It is possible to write templated drivers for testing
many parts of templates
January 20, 2002
57
Abstraction
The process of removing detail from a representation.
Allows us to look at a problem in various levels of
detail.
leave out details that are irrelevant for a given
consideration
OO technologies use abstraction extensively
inheritance hierarchy, for example
system models whose detail increases during
development
January 20, 2002
58
Layers of abstraction
Layers of abstraction in the development process are
paralleled by layers of testing analysis
If we begin testing analysis with the highest levels of
abstraction of development models,
we provide a more thorough examination of the
development product
and, therefore, a more effective and accurate set of
tests
January 20, 2002
59

Good Object Oriented Testing Slides

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Good Object Oriented Testing Slides

Hochgeladen von

Copyright:

Verfügbare Formate

Testing Object-Oriented Software

January 20, 2002

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

What is software testing?

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

Testing vs. Quality Assurance

ECEN5033 - OO Testing University of Colorado

Whats special about testing OO software?

January 20, 2002

ECEN5033 - OO Testing University of Colorado

OO Testing Is Still Testing

January 20, 2002

ECEN5033 - OO Testing University of Colorado

OO Testing Is Not Just Old Style Testing

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

Avoid the bugging phase

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

Objects from a testing perspective

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

Messages from a testing perspective

may include actual parameters

January 20, 2002

ECEN5033 - OO Testing University of Colorado

Those issues are the primary focus of

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

Interfaces from a testing perspective

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

Two special operations

January 20, 2002

ECEN5033 - OO Testing University of Colorado

What do we expect of a class specification?

January 20, 2002

ECEN5033 - OO Testing University of Colorado

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

January 20, 2002

ECEN5033 - OO Testing University of Colorado

Behavior of the instances of a class

ECEN5033 - OO Testing University of Colorado