11/09/02(c) 2002 Bo Sanden, Colorado Tech.1 OO Testing.

11/09/02 (c) 2002 Bo Sanden, Colorado Tech. 1

OO Testing


OO and testing

• It is often said that OO reduces testing because of the reuse of inherited methods– This is not always true

• “The only really tangible benefit of object-oriented programming is that it allows you to change things easily”

Martin Fowler, 1997


Object-oriented testing: Myth and Reality

Robert V. Binder,

Object Magazine, May 1995

www.rbsc.com/pages/myths.html


Perceptions about testing objects

• Testing by poking around becomes widespread and accepted practice:– The developer shows that objects do something

useful without crashing– Someone else gets to try a few dirty tricks to

break the software• Impossible to say how much has been tested• No test case design,

– A powerful defect prevention strategy


Myth 1

• Testing is unnecessary– Development is iterative so each class is tested

by being reused in several builds– OO languages don’t allow as many mistakes as

earlier languages

• Reality: Human error as likely as ever– Reuse does not guarantee coverage– “Trust but verify”


Myth 2

• Testing gets in the way – Class development is exploratory, like telling a

story; it flows and grows– Testing is destructive, rote; not a good use of

developer talent

• Reality: A good testing strategy contributes


Myth 3

• Testing is a structured / waterfall idea

• Reality: Testing can be incremental and iterative– “Design a little, code a little, test a little”


Myth 4

• Testing of object-oriented software is trivial

• Reality: Hunches about testing coverage are notoriously optimistic– An abstract view of the software dynamics is

necessary: control flow, data flow, state space– Little automation is available


Myth 5

• Automated (scripted) GUI testing is sufficient

• Reality: Coverage is uncertain– The approach is of little use for embedded

systems


Myth 6

• Programming errors can be avoided – They are simply an indication of bad work

habits

• Reality: OO systems tend to have more components and more interfaces– Interface errors surface only at integration


Myth 7

• Testing OO software is the same as for “conventional” software – All we need is black-box testing, which ignores

the internal structure

• Reality: Structure matters.– Inheritance, polymorphism, etc., create

opportunities for new kinds of errors


Myth 8

• Conventional testing is useless for objects– Control flow testing is meaningless since

methods are small

• Reality: Conventional techniques can be adapted


Myth 9

• By extending known foundation classes, you eliminate errors

• Reality: Each subclass is a different context for inherited features– Methods must be retested in their new contexts– (See Schach)


OO TestingStephen R. Schach

Software Engineering

Chapter 12


General• A method, m( ), often changes the state of the

object – O – that it is invoked on. • To see if m( ) generates the correct result, you

must often call another method, O.n( ), that returns the appropriate part of the state.

– Example: The methods deposit( ) and getBalance( ) on an object of class Account

• For testability, each class should have all the necessary “getter” methods.


Testing inherited methods

• An inherited method, once tested in the parent class, may need to be retested in the new environment of a child class

• Example: Tree hierarchy


class Rooted_Tree { …

void display_node_contents(Node a);

// display_node( ) uses print( )

void print (Node b);}

class Binary_Tree: public Rooted_Tree { …

void display( );

// Overriding method; uses print( )}

class Balanced_B_Tree: public Binary_Tree { …

void print(Node b);

// Overriding method; used by inherited display( )}


• display( ) has been tested when operating on a Binary_Tree object

• It must be retested on a Balanced_B_Tree object since it now calls a different print( ) method

11/09/02(c) 2002 Bo Sanden, Colorado Tech.1 OO Testing.

Documents

Transcript of 11/09/02(c) 2002 Bo Sanden, Colorado Tech.1 OO Testing.