Testing in OO Environment

1
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

2
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?
3
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
4
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
5
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?
6
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.
7
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 -
-
8
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
9
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
10
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
11
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( ) coutltlt volume is ltlt area(
  ) length // the area( ) method is not bound
• Class Cylinder public Cube
• virtual float area( ) return (3.14 length2)
  // 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.

12
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).newi
  nstance( )

Is equivalence class testing of valid vs invalid
shape good enough? Do you need to test everyone
of the valid shape?
13
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
• - - -
• public void speak ( )
• system.out.println(woof woof)

All Branch Test will take care of both cat and
dog ?-----
14
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

15
Basic Levels of Testing in OO
System Test
Same as before testing the whole system
Test relations and Inheritance Encapsulati
on Polymorphism
Unit A Integration test
Unit X Integration test
Unit Testing
Test class and class Inheritance
16
More Considerations of Unit Testing

• 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.
• 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)
• Also, we need to deal with abstract method and
  abstract class which are generic concept. (It is
  almost like a stub itself).

17
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