November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 1 Testing...

November 13, 2006 ECEN 5543 / CSCI 5548 – Testing OOUniversity of Colorado, Boulder

1

Testing Object-Oriented Software Principles Summary

ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs

University of Colorado, Boulder


2

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.


3

What’s 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


4

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


5

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


6

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


7

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


8

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.


9

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.”


10

Outline• Objects• Objects from a

testing perspective• Messages• Messages from a

testing perspective• Interfaces• Interfaces from a

testing perspective• Operations• Operations from a

testing perspective

• Classes• Classes from a

testing perspective

• Inheritance from a testing perspective

• Substitution principle

• Substitution principle from a testing perspective

• Abstraction• Abstraction from a

testing perspective


11

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– associate instance attributes with methods


12

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


13

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


14

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 if 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 msg is processed

– implement the interfaces expected by the receiver


15

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


16

Basic terms

ClassA

SubClassA1 SubClassA2


17

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.


18

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 object’s lifetime

• Differ from accessors & modifiers– invoked implicitly as a result of the birth and death

of objects


19

What do we expect of a class specification?• A description of what a class represents.

It’s 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


20

Reminder• Preconditions

– Conditions that must hold before the operation can be invoked.

• Post conditions– Conditions that must hold after the operation is

performed. Guaranteed.• Invariants

– Conditions that must always hold within the lifetime of the object

– An operation’s method may violate invariants during execution but it must “hold again” by completion.


21

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 and ... more parameter testing


22

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


23

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)


24

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.


25

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


26

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


27

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


28

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


29

Substitution Principle of Inheritancefrom a testing perspective

• 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, don’t use inheritance because

you are too lazy to specify a class that is similar but is-not-a-kind-of


30

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


31

Layers of abstraction from a testing perspective

• 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


32

Date post:	20-Dec-2015
Category:	Documents
View:	216 times
Download:	1 times

November 13, 2006ECEN 5543 / CSCI 5548 – Testing OO University of Colorado, Boulder 1 Testing...

Documents