1. Object-Oriented Software Testing

2. C-S 5462 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

3. C-S 5463 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

4. C-S 5464 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

5. C-S 5465 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 100) System.out.println (“ Invalid reading ”); else if ((w >= 0 && w = 80 && w <= 100)){ System.out.println (“Water level exceeded the limit – EMERGENCY”); alarmObject.raiseAlarm (waterLevel); } else System.out.println (“ Normal range ”); }

6. C-S 5466 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 Instructor: discuss the consequences of using stubs

7. C-S 5467 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

8. C-S 5468 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, …

9. C-S 5469 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

10. C-S 54610 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

11. C-S 54611 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

12. C-S 54612 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 }

13. C-S 54613 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 “); }

14. C-S 54614 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

15. C-S 54615 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

16. C-S 54616 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

17. C-S 54617 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

18. C-S 54618 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

19. C-S 54619 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

20. C-S 54620 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

21. C-S 54621 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