Object-Oriented Object-Oriented Software TestingSoftware Testing

C-S 546 2

Object-Oriented Software Testing

• Research confirms that testing methods proposed for procedural approach are not adequate for OO approach

• OO software testing poses additional problems due to the distinguishing characteristics of OO

• Testing time for OO software found to be increased compared to testing procedural software

C-S 546 3

Brief review of software testing

• Classifications based on testing stages– Unit testing

– Integration testing

– System testing

– Acceptance testing

• Classifications based on test case generation methods– Black-box testing

– White-box testing

C-S 546 4

Brief review of software testing (continued)

• Use of “stubs” in software testing– If two units are supposed to interact with each

other, and only one unit has been developed, then a “template” or “stub” of the other unit can be developed just to test the interactions

– Advantage: the developer of the first unit need not wait until the second unit is developed

– Disadvantage: testing must be repeated after the actual second unit is developed

C-S 546 5

Testing methods within a class using STUBspublic class WaterTankController { public static void main (String[] args) { Sensor sensorObject = new Sensor (); Alarm alarmObject = new Alarm();

int waterLevel = sensorObject.getReading (); checkReading (waterLevel); } public static void checkReading (int w) { if (w < 0 || w > 100) System.out.println (“ Invalid reading ”); else if ((w >= 0 && w <= 20) || (w >= 80 && w <= 100)){

System.out.println (“Water level exceeded the limit – EMERGENCY”); alarmObject.raiseAlarm (waterLevel); } else System.out.println (“ Normal range ”); }}

C-S 546 6

Testing Methods … STUBs (continued)

public class Sensor {

…

public int getReading () {return 10;}

}

public class Alarm {

…

public void raiseAlarm (int n) {

System.out.println (“ Alarm raises ”);

}

}

Stub

Stub

Instructor: discuss the consequences of using stubs

C-S 546 7

Issues in Object-Oriented Software Testing

• Unit of testing– method or class? what are the consequences?

• Implications of encapsulation and composition– how to test encapsulation?

• Implications of inheritance– superclass needs to know subclasses?

• Implications of Polymorphism– behavioral equivalence

C-S 546 8

Unit of testing – method as unit

• testing methods and tools for procedural approach can be used to test individual methods in each class

• stubs used for interacting methods from other classes

• consequences: access restrictions on methods and encapsulation are not tested

• nevertheless, methods must be tested individually to ensure the correctness of algorithms, parameter passing, …

C-S 546 9

Unit of testing – class as unit

• a more common view agreed by most people in OO community

• required:– individual methods must be tested for correctness

• OO metrics report:– classes that have methods whose parameters are objects

are more likely to contain more errors than the methods that do not contain objects as parameters

C-S 546 10

Implications of inheritance

• common approach – flatten a subclass by copying the code of inherited

methods and attributes• Instructor: explain with an example

– each subclass must be tested individually– after testing, the inheritance hierarchy must be restored

back

• consequences– any change in a superclass requires re-testing of the

superclass and all its descendants

C-S 546 11

Implications of polymorphism

• superclass needs to know all its descendants – reason: subclass objects are expected to behave

as if superclass objects

• consequences:– any change in subclass requires re-testing of the

subclass and all its superclasses because of polymorphic substitutions

C-S 546 12

Example – polymorphic substitutions

public class Rectangle {

public Rectangle (…) { …}

public boolean isEnclosed (Point p) {…} // returns true if Point p is //enclosed inside this rectangle

….

}

// “RoundedRectangle” inherits “Rectangle” – keyword in Java is “extends”

public class RoundedRectangle extends Rectangle {

public RoundedRectangle (…) {…}

public boolean isEnclosed (Point p) {…} // redefined version of the //superclass method

//– points at the four corners will be ignored

}

C-S 546 13

Client code that uses Rectangle and RoundedRectangle

public class GeometricObjects {

public static void main (String[] args) {

Rectangle rect;

RoundedRectangle round = new RoundedRectangle(…);

rect = round; // polymorphic substitution

Point p = new Point (…); // take the top left corner of the rectangle

if (rect.isEnclosed(p)) System.out.println (“ Point is enclosed “);

else System.out.println (“ Point is not enclosed “);

}

}

C-S 546 14

OO Testing – some more challenges

• parameterized classes (templates)– a class such as Course[T] must be tested for every substitution

of T within that application

• static variables– those that are common for all instances of a class– must be tested for every new instance of this class to ensure

that the static variable is accessible and is consistent with respect to its access

• languages that support assertions such as pre and post-conditions for methods (e.g., Eiffel, COLD)– body of the method must be executed to make sure that each

pre and post-condition is checked

C-S 546 15

UML and OO testing

• Use case model– describes the interactions of a typical user with

the system– GUI testing scenarios covered system

testing– details of use case instances will help identify

the parameters, and return values– Caution: use case instances may not provide

the types of parameters and return values

C-S 546 16

UML and OO testing (continued)

• Logical view– described by class and object diagrams– describes the static relationships between

classes and objects– can be tested manually by code walkthrough

and/or by executing objects– system testing

C-S 546 17

UML and OO testing (continued)

• State model– state machines are used extensively in software testing

– procedural approach uses one state machine that describes the states of the entire system

– OO approach describes the state of each object separately

• modularity

• separation of concern

– unit testing

C-S 546 18

UML and OO testing (continued)

• State model (continued)– the actions included in a transition correspond to

methods in the classes– testing each transition cover all methods that

manipulate the object– testing the events correspond to the interactions among

the objects– testing all the states of an object leads to the evaluation

of the cohesion of the object• Cohesion: appropriateness of the object to complete its

expected role in the application

C-S 546 19

UML and OO testing (continued)

• Interaction view– described by sequence and collaboration

diagrams– testing sequence of message passing test all

possible communication scenarios • Includes concurrency

– testing timing constraints in message passing leads to performance testing

– unit testing and integration testing

C-S 546 20

UML and OO testing (continued)

• Activity diagrams– describe the details of a use case or the details

of a method– synonymous to “data flow”– testing an activity diagram is similar to the flow

graph of a method or a use case• white-box testing

C-S 546 21

References

• Paul C. Jorgensen, “Software Testing – A Craftsman’s Approach” (Second Edition), CRC Press, 2002, ISBN: 0849308097.

• Robert V. Binder, “Testing Object-Oriented Systems”, Addison-Wesley, 2000, ISBN: 0201809389.

• http://oo-testing.com/bib