Testing with OO
• OO has several key concepts:
–
–
–
–
Class & object instantiation
Encapsulation
Inheritance and reuse
Polymorphism and late (dynamic) binding
• Are there special concerns when we test
software developed under OO
methodologies?
Class and Object instantiation
• There are at least two concerns:
– Should we 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; - - - -
– If there is a large method inside the Class and we
know (via whitebox testing approach) that the
method invokes other methods in other Classes,
should we follow (test) the thread of methods
across different Classes?
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)
– Private (hidden)
– Protected (secret)
• Test the access of encapsulated data
• Test the access of encapsulated methods
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
•
•
One may want to test subclass access of the “encapsulated” data or
methods in the super-class.
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 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?
Polymorphism and Late Binding
•
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.