Object-Oriented Software Testing

1. Object-Oriented Software Testing

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 STUBs public 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 C-S 546