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

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

What is a “unit” in OO ? A “unit” of code for unit testing before was left with a loose definition of a module, –a sequence of code that performs something, –a compiled program, –something assigned to 1 person In OO we have the same problem with the definition of a “unit” in unit testing. Is it: –A method? –A set of code that performs something? –A Class? Considering Class as a “unit” has a lot of support among testers., but it is not a fixed law or something

Class and Object instantiation There are at least 2 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 example on page 287. The exchange of “positions” of these two may be different depends on the design 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 5 / 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 1Sibling 2 Grand_Sibling 1 (method1) Note: JAVA does not allow multiple inheritance overriddenOverridden 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

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

Polymorphism via “interface” class (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 ?-----

OO concepts and testing Assume a “unit” is a CLASS. –Inheritance can be dealt with at the subclass level through unit testing the “flattened” subclass as the basic “unit”. Flattened class is the class expanded to include all the inherited methods (operations) and variables/constants (attributes) –Encapsulation can be dealt with by both unit testing the individual class and integration testing the related classes. (More burden is placed on the integration test especially if the design is “tightly” coupled classes.) –Overload and polymorphism can be dealt with unit testing the overload or the polymorphic function individually and then use integration testing to further test the overriding and the polymorphism mechanisms

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

More Considerations of Unit Testing 1.Each method as a “unit” –Once a method of interest is designed and written one still needs to develop “scaffolding” test code such as stubs for the yet-to-complete other methods and driver for the “main” program to test the finished method. 2.The completed class as a “unit” –All the methods are and the data are available for testing. –We may view the class in 3 ways: –Source code level (reviewing the code – possibly with “flattened” class) –Compiled code level ( code inheritance takes place and all the classes in the hierarchy above the class must be available) –Execution code level (code is constructed and the interactions among the methods can be tested much like an integration test within a class) 3.Also, we need to deal with abstract method and abstract class which are generic concept. (It is almost like a stub itself).

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