Chapter 15

Object-Oriented Testing

Testing in OO Environment

• The reasons for testing is not any different for any of the design and implementation methodologies, including OO methodology.

– Find faults and fixing them before releasing– Show that the software works (at least in chosen

areas)

• In OO we are especially interested in testing because we want to “reuse” the tested objects.

• Does our approach have to change because of OO?– Not really - - - but we do have to focus on a few

characteristics

Issues in Testing Object-Oriented Software

• How is object-oriented (o-o) software different/special?– Need to clarify unit– Composition vs. decomposition– No reason for integration testing based on functional decomposition tree– Can still use the (better) idea of Call Graph based integration

• Properties of an o-o programming language– Inheritance– Encapsulation– Polymorphism

• Message communication– Message quiescence– Event quiescence

Basic Levels of Testing in OO

Unit Testing

Unit AIntegration test

Unit XIntegration test

System Test

What is a “unit”In OO?

Same as before;testing “related” units as a group

Same as before;testing the wholesystem

Units in Object-Oriented Software

• Guidelines for units– A unit is the smallest software component that can be

compiled and executed. (traditional view, usually in procedural code)

– A unit is a software component that would never be assigned to more than one designer to develop. (Project management view, appropriate for both procedural and o-o software)

– Unit developer does detailed design, coding, and unit level testing

• Candidate o-o units– A single method– A class (generally accepted view)

Single Methods as Units

• Appropriate for large classes• Consistent with the one designer/one unit practice• Single method testing

– reduces to unit testing for procedural units– o-o units are typically less complex (cyclomatic) than

procedural units

• This choice mandates “intra-class” integration testing.

Class and Object instantiation

• There are at least two concerns with viewing class as a “unit”:

1. We should view Class as a fundamental unit and test it as an independent entity by itself.

• What and how much “scaffolding” code do we need to write to invoke and test this Class. – e.g. Class1 x1; - - - -– You may need to write the public static void “main” method to test the

class (possible scaffolding code)

2. If there is a large method inside the Class and we know (via white-box testing approach) that the method invokes other methods in other Classes, should we follow (test) the thread of methods across different Classes?

– the module-module (mm-path) approach may be employed for testing the “thread” of methods, that may go beyond one Class

scaffolding

integration

3 important concepts in OO

1. Encapsulation: – In OO, the notion of self contained and only know/operate

within its own domain is very important– Good encapsulation gives rise to good reusable classes

that can be composed with other classes to deliver more service.

– We are also after highly cohesive and loosely coupled units with encapsulation.

2. Inheritance:– A way to gain on the concept of reuse through a class

taking (inheriting) portions from a super class.

3. Overload/Polymorphism”– Another way to gain on the reuse concept through using

parts of class or method for different purposes based on the passed parameter or based on run time usage (late binding).

How do these concepts affect us in testing?

Encapsulation

• Both data and methods may be encapsulated and protected. Depending on the programming language used there may be slight differences in implementing the encapsulation mechanism:

– Public (visible) - - - pretty much same in all languages– Private (hidden) - - - only methods in the class can access– Protected (secret)- - - subclass methods can access

• Test the access of encapsulated data• Test the access of encapsulated methods

Read the discussion on the positions of “dial’ and “lever” of the windshield wiper exampleon page 287. The exchange of “positions” of these two may be different depends on thedesign and how the data is encapsulated.

Inheritance Example (JAVA)• One may want to test the methods in the inherited

class which were previously tested in the super-class.

• An example is a method, m1, that only returns positive integers and is used in another method, m2, as a divisor. An inherited subclass modifies (over rides) m1 to allow all integers, including zero. (We will need to ensure that the inherited and previously tested m2 is retested).

public class Example { int y;public int m1 { - - y = (test * test) +1; return y; }public void m2 { - - z = w / y ;}

import Example ;public class Example2 extends Example { - - public int m1 { - - y = test * test ; return y; } - -}

Similar Inheritance Problem Example (C++)

Class Test1 {

int some_variable;

.

.

int method1 ( ) { return 1; }

int method2 ( ) { return 1 / method1( ); }

}

Class Test_child : Public Test1 {

int mehtod1 ( ) { return 0; }

}

Original CLASS

Inherited CLASS over-riding method1

Inheritance

• Do we need to test multiple inheritance, where there may be conflicts in inheritance?– Two subclasses, Sub1 and Sub2, are inherited from a super-

class, S1, and they both modify the method, method1, but differently. If we further inherit from both Sub1 and Sub2, what should we expect method1 to be like?

Varx : int

method1 ( )method2 ( )

Mother

Sibling 1 Sibling 2

Grand_Sibling 1

(method1) (method1)

Note: JAVA does not allowmultiple inheritance

overridden Overridden differently

Inheritance• Inheritance provides us with the ability to reuse (and save both

implementation and testing expenses) what is there and make incremental changes by creating a subclass by either adding to or modifying the :

– Instance variable– Methods

• Using “Flattened Class” concept:

1. One may want to test subclass access of the “encapsulated” data or methods in the super-class.

2. One may want to test all the methods in the inherited class which were previously tested in the super-class.

• An example is a method, m1, that only returns positive integers and is used in another method, m2, as a divisor. An inherited subclass modifies m1 to allow all integers, including zero. (We will need to ensure that the inherited and previously tested m2 is retested).

3. Do we need to test multiple inheritance, where there may be conflicts in inheritance?

• Two subclasses, Sub1 and Sub2, are inherited from a super-class, S1, and they both modify the method, m1, but differently. If we further inherit from both Sub1 and Sub2, what should we expect m1 to be like?

Testing flattened Classes of all inherited subclasses will cause duplication of testing the same (non-overridden) methods that appear in all the inherited subclasses

Implications of Inheritance

Account

accountNumberBalance

getBalance()setBalance()

checkingAccount

checkProcessingChargecheckNumber

postCharge()

savingsAccount

interestRate

postInterest()

Implications of Inheritance—Flattened Classes

checkingAccount

accountNumberBalancecheckProcessingChargecheckNumber

getBalance()setBalance()postCharge()

savingsAccount

accountNumberBalanceinterestRate

getBalance()setBalance()postInterest()

Example—O-O Windshield Wiper

Class lever(leverPosition;private senseLeverUp(),private senseLeverDown() )

Class dial(dialPosition;private senseDialUp(),private senseDialDown() )

Class wiper(wiperSpeed;setWiperSpeed(newSpeed) )

Which unit controls the interaction between the Lever and the Dial?

Wiper

Speed Lever Position Dial Position

Compute Speed

Lever

position

Sense Up Sense Down

Dial

Sense Left Sense Right

position

Saturn Windshield Wiper Objects

Windshield Wiper Class Behavior

Off

Int

Low

High

leverUp

leverUp

leverUp leverDown

leverDown

leverDown

Lever

0 wipes/minute

6 wipes/minute

12 wipes/minute

20 wipes/minute

30 wipes/minute

60 wipes/minute

Wiper

dialUp

dialUp dialDown

dialDown

1

2

3

Dial

Unit Testing for Windshield Wiper Classes

• Can test only the Lever and Dial classes directly.• Test cases to verify that event-oriented methods

make correct changes to the position attributes.• Need “mock objects” (o-o analog of drivers for

procedural code) to provide inputs to test the wiper class.

• Note how the “line” between unit and integration testing is blurred!

Sample Unit Test Case for Lever

Test Case Name Test Sense Up method

Test Case ID Lever-1

DescriptionVerify that the LeverUp method correctly changes the value of the position attribute

Pre-Conditions 1. position = Off

Input(s) Expected Output(s)

1. move lever to Int 2. position = Int

3. move lever to Low 4. position = Low

5. move lever to High 6. position = High

Post condition(s)  1. position = High

Test Result? Pass/Fail

Test operator Paul Jorgensen

Test Date Dec. 8, 2013

WiperLever

leverUp

leverUp

leverUpleverDown

leverDown

leverDown

dialUp

dialUp

dialDown

dialDown

Dial

1

2

3

0 wipes/minute

InState(Int)

InState(2) InState(1)

InState(Off)

30 wipes/minute

60 wipes/minute

InState(Low)

InState(High) InState(Low)

InState(Int)

InState(3) InState(2)

InState(1)

InState(2)

InState(3)

6 wipes/minute

12 wipes/minute

20 wipes/minute

Off

Int

Low

High

Windshield Wiper StateChart

StateChart-Based Testing for the Windshield Wiper

• Need an engine to execute the StateChart– execute “interesting” scenarios– save paths as skeletons of system test cases

• The InState events show how the Wiper class can be tested once the Lever and Dial classes have been tested.

Sample System Level Test CaseTest Case Name Exercise all wiper speeds

Test Case ID WindshieldWiper-1

Description

The windshield wiper is in the OFF position, and the Dial is at the 1 position; the user moves the lever to INT, and then moves the dial first to 2 and then to 3; the user then moves the lever to LOW.; the user moves the lever to High.

Pre-Conditions

1. The Lever is in the OFF position

2. The Dial is at the 1 position

3. The wiper speed is 0

Input events Output events

1. move lever to INT 2. speed is 6

3. move dial to 2 4. speed is 12

5. move dial to 3 6. speed is 20

7. move lever to LOW 8. speed is 30

9. move lever to HIGH 10. speed is 60

Post conditions

1. The Lever is in the HIGH position

2. The Dial is at the 3 position

3. The wiper speed is 60

Polymorphism and Late Binding (in C++)• Polymorphism and late binding is a special feature that allows us to have

multiple behavior based on which class a statement is bound to. e.g. in C++Class Cube{

protected:

float length;

public:

virtual float area( ) {return (length* length);} // area of square

void set_length(float z) {length = z} // set passed parameter, length

void volume( ) {cout<< “volume is” << area( ) * length;} // the area( ) method is not bound

};

Class Cylinder: public Cube

{

virtual float area( ) {return (3.14* length**2);} // area of circle

} .

. Cube c1, Cylinder cyl1;

. c1.volume( ); // give us the volume of cube

cyl1.volume( ); // give us the volume of circle

•Both classes must be tested, especially if one of them is a division by length.

Polymorphism via dynamic instantiation (in JAVA) class Shape { - - - - - - - } - - class Rectangle extends Shape { - - - - } class Triangle extends Shape { - - - - } class Circle extends shape { - - - - } - -import Rectangle;import Triangle;import Circle;public class Example {public static void main ( String[ ] args) - -String S = get_shape_type ( ) ; // some method that reads and returns a string to SShape myFigure;myFigure = (Shape) java.lang.class.forName(S).newinstance( ); /* myFigure is instantiated to what the string read in --- hopefully it is rectangle, circle or triangle *//* Note that it is “casted’ as type Shape, which is the parent Class */ - - }

Is equivalence class testing of valid vs invalid shape good enough?Do you need to test everyone of the valid shape?

Polymorphism via “interface” (in JAVA)

public interface Speaker { - - - public void speak( ); }

public class cat implements Speaker { - - - public void speak ( ) { system.out.println(“meow”); } }

public class dog implements Speaker { - - - public void speak ( ) { system.out.println(“woof woof”);} }

Import cat;Import dog;Public class AnimalTalk{ public static void main ( string[ ] arg) { Speaker current; system.out.println(“enter 1 or 2”); /* 1 = cat and 2 = dog */ int j = keyboard.readInt ( ); if (j == 1) current = new cat ( ); else current = new dog ( ); - - current.speak ( ); - - } }

All Branch Test will take care of both cat and dog ?-----

Basic Levels of Testing in OO

Unit Testing

Unit AIntegration test

Unit XIntegration test

System Test

Test class andclass Inheritance

Test relations andInheritance;Encapsulation; Polymorphism

Same as before;testing the wholesystem

Integration Testing

• Assumes the unit or units are unit-tested.• Use the collaboration diagram and the

sequence diagram from UML to design the integration test cases.

12

3

Collaboration diagram whereboxes are classes and numberedarrows indicate sequenced messages

Sequence diagram where the boxesare classes and the arrows indicatethe sequence of messages

Testing Object-Oriented NextDate

• Example—our familiar NextDate• Rewritten here in object-oriented style• One Abstract Class—CalendarUnit• Classes

– testIt– Date– Day– Month– Year

• (See text for pseudo-code)• Program graphs in next few slides

Program Graphs of Date Methods

1

2

3

testIt Date.constructor

4

5

6

7

Date.printDate

19

20

Date.increment

1512

13

14

8

9

10

11

16

17

18

Program Graphs of Day Methods

Day.setCurrentPos

a

b

23

24

25

Day.setDay

Day.getDay

26

27

Day.increment

31 32

33

28

29

30

21

22

Day.constructor

Program Graphs of Month Methods

boolean.increment

50 51

52

47

48

49

36

37

38

Month.setMonth Month.getMonthsize

43 44

45

46

41

42

34

35

Month.constructor Month.setCurrentPos

a

b

Month.getMonth

39

40

Program Graphs of Year Methods

57

58

59

boolean.increment boolean.isLeap

62 63

64

60

61

Year.getYear

55

56

Year.setCurrentPos

a

b

53

54

Year.constructor

ooNextDate Collaboration Diagram

testIt Date

Year

Month

Day

1. create2. increment3. printDate

1. create2. increment3. getYear

1. create2. increment3. getMonth4. setMonth

1. create2. increment3. getDay4. setDay

printDate Sequence Diagram

testItDate

.printDateDay

d.setDayMonth

m.setMonthYear

y.setYear

Time

1. printDate2. setDay

3. setMonth

4. setYear

MM-Paths for O-O Software

• Definition: An object-oriented MM-Path is a sequence of method executions linked by messages.

• Call Graph slightly revised– nodes are methods– edges are messages

• Next three slides show sample Call Graphs for ooNextDate

All MM-Paths as a Call Graph

testIt

Main

Date

getDate()

increment()

printDate()

Day

Day()

setCurrentPos()

increment()

setDay()

getDay()

Year

Year()

setCurrentPos()

increment()

setYear()

getYear()

Month

Month()

setCurrentPos()

increment()

setMonth()

getMonth()

getMonthSize()

msg1

msg2msg3

msg4

msg5

msg6

msg7

msg8

msg9

msg10

msg11

msg12

msg13

msg14

msg15msg16

msg17

msg18

msg19

msg20

msg21

MM-Path for January 3, 2013

testIt

Main

Date

getDate()

increment()

printDate()

Day

Day()

setCurrentPos()

increment()

setDay()

getDay()

Year

Year()

setCurrentPos()

increment()

setYear()

getYear()

Month

Month()

setCurrentPos()

increment()

setMonth()

getMonth()

getMonthSize()

msg1

msg4

msg5

msg6 msg15msg16

msg18

msg19

msg21

MM-Path for April 30, 2013

testIt

Main

Date

getDate()

increment()

printDate()

Day

Day()

setCurrentPos()

increment()

setDay()

getDay()

Year

Year()

setCurrentPos()

increment()

setYear()

getYear()

Month

Month()

setCurrentPos()

increment()

setMonth()

getMonth()

getMonthSize()

msg2

msg4

msg5

msg7

msg11

msg17

msg20

Integration Test Coverage Metrics

• Coverage metrics with respect to Call Graph• Given a set of test cases that

– covers each method (node coverage)– covers each message (edge coverage)– covers each path

System Testing for O-O Software

• Nearly equivalent to system testing for procedural software.

• Some possibilities for sources of system test cases...– Use cases– Model-Based system testing

Second Example (event-driven system testing)

Currency Converter

Brazil

Canada

European community

Japan

Compute

Clear

Quit

U.S. Dollar amount

Equivalent in ...

Second Example (continued)

Currency Converter

Brazil

Canada

European community

Japan

Compute

Clear

Quit

U.S. Dollar amount

Equivalent in ...

label1

label2

label3

optBrazil

optCanada

optEU

optJapan

txtDollar

lblEquivAmount

cmdCompute

cmdClear

cmdQuit

frmCurrConv

Input Events for the Currency Converter

Input Events Input Events

ip1 Enter US Dollar amount ip2.4 Click on Japan

ip2 Click on a country button ip3 Click on Compute button

ip2.1 Click on Brazil ip4 Click on Clear button

ip2.2 Click on Canada ip5 Click on Quit button

ip2.3 Click on European Community

ip6 Click on OK in error message

Output Events for the Currency Converter

Output Events Output Events

op1 Display US Dollar Amount op4 Reset selected country

op2 Display currency name op4.1 Reset Brazil

op2.1 Display Brazilian Reals op4.2 Reset Canada

op2.2 Display Canadian Dollars op4.3 Reset European Community

op2.3 Display European Community Euros op4.4 Reset Japan

op2.4 Display Japanese Yen op5 Display foreign currency value

op2.5 Display ellipsis op6 Error Msg: Must select a country

op3 Indicate selected country op7 Error Msg: Must enter US Dollar amount

op3.1 Indicate Brazil op8 Error Msg: Must select a country and enter US Dollar amount

op3.2 Indicate Canada op9 Reset US Dollar Amount

op3.3 Indicate European Community op10 Reset equivalent currency amount

op3.4 Indicate Japan

StateChart for the Currency Converter

In Storage

Idle

U.S. Dollar Amount SelectedCountry Selected Missing Country and Dollar Message

Missing U .S. Dollar Message Missing Country Message

Both Inputs Done

Equiv . Amount Displayed

Ip2/op2,op3

Ip1/op1

Ip3/op5

Ip3/op7Ip3/op7

Ip6Ip6

Ip1/op 1

Ip2/op2,op 3

Ip1/op 1Ip2/op2,op 3

Ip6

Ip3/op 8

Ip4

GUI action

Executing

Ip4___________________

op2, op 4, op9, op10

ip 5 Quit End Application

Sample System Level Test Case

System test Case -3 Normal usage (dollar amount entered first)

Test performed by Paul Jorgensen

Pre-Conditions txtDollar has focus

Input events Output events

1. Enter 10 on the keyboard 2. Observe 10 appears in txtDollar

3. Click on optEU button4. Observe “euros” appears in label3

5.Click cmdCompute button6. Observe “7.60” appears in lblEquivAmount

Post-Conditions cmdClear has focus

Test result Pass (on first attempt)

Date run May 27, 2013