Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object-Oriented Testing

Similar presentations


Presentation on theme: "Object-Oriented Testing"— Presentation transcript:

1 Object-Oriented Testing
Chapter 15 Object-Oriented Testing

2 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

3 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

4 Basic Levels of Testing in OO
System Test Same as before; testing the whole system Unit A Integration test Unit X Integration test Same as before; testing “related” units as a group Unit Testing What is a “unit” In OO?

5 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)

6 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.

7 Class and Object instantiation
There are at least two concerns with viewing class as a “unit”: 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) 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

8 3 important concepts in OO
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. Inheritance: A way to gain on the concept of reuse through a class taking (inheriting) portions from a super class. 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?

9 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 example on page 287. The exchange of “positions” of these two may be different depends on the design and how the data is encapsulated.

10 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; }

11 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

12 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? Mother Varx : int method1 ( ) method2 ( ) Note: JAVA does not allow multiple inheritance Sibling 1 Sibling 2 (method1) (method1) overridden Overridden differently Grand_Sibling 1

13 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: One may want to test subclass access of the “encapsulated” data or methods in the super-class. 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). 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

14 Implications of Inheritance

15 Implications of Inheritance—Flattened Classes

16 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?

17 Saturn Windshield Wiper Objects
Speed Lever Position Dial Position Compute Speed Lever Dial position position Sense Up Sense Left Sense Down Sense Right

18 Windshield Wiper Class Behavior

19 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!

20 Sample Unit Test Case for Lever
Test Case Name Test Sense Up method Test Case ID Lever-1 Description Verify 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

21 Windshield Wiper StateChart

22 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.

23 Sample System Level Test Case
Test 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

24 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.

25 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 S Shape 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?

26 Polymorphism via “interface” (in JAVA)
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 ( ); } public interface Speaker { public void speak( ); } public class cat implements Speaker { public void speak ( ) { system.out.println(“meow”); } public class dog implements Speaker { system.out.println(“woof woof”);} All Branch Test will take care of both cat and dog ?-----

27 Basic Levels of Testing in OO
System Test Same as before; testing the whole system Test relations and Inheritance; Encapsulation; Polymorphism Unit A Integration test Unit X Integration test Unit Testing Test class and class Inheritance

28 Assumes the unit or units are unit-tested.
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. 1 2 3 Collaboration diagram where boxes are classes and numbered arrows indicate sequenced messages Sequence diagram where the boxes are classes and the arrows indicate the sequence of messages

29 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

30 Program Graphs of Date Methods

31 Program Graphs of Day Methods

32 Program Graphs of Month Methods

33 Program Graphs of Year Methods

34 ooNextDate Collaboration Diagram

35 printDate Sequence Diagram

36 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

37 All MM-Paths as a Call Graph

38 MM-Path for January 3, 2013

39 MM-Path for April 30, 2013

40 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

41 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

42 (event-driven system testing)
Second Example (event-driven system testing)

43 Second Example (continued)

44 Input Events for the Currency Converter
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

45 Output Events for the Currency Converter
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

46 StateChart for the Currency Converter
In Storage Idle U . S Dollar Amount Selected Country Selected Missing Country and Dollar Message Missing U Dollar Message Missing Country Message Both Inputs Done Equiv Amount Displayed Ip 2 / op , 3 1 5 7 6 8 4 GUI action Executing ___________________ 9 10 ip Quit End Application

47 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 button 4. Observe “euros” appears in label3 5.Click cmdCompute button 6. Observe “7.60” appears in lblEquivAmount Post-Conditions cmdClear has focus Test result Pass (on first attempt) Date run May 27, 2013


Download ppt "Object-Oriented Testing"

Similar presentations


Ads by Google