Object Oriented Testing in Software Testing Pedagogy Zone

Testing object oriented software presents some new challenges. Many conventional techniques are still appropriate. For example, functional testing of object oriented software will be no different from functional testing of conventional software. Test cases will be developed based on the required functionality as described in the requirement documentation. However, structural testing of object oriented software will be very different. Two structural testing approaches will be covered: MM testing and function pair testing.

Conventional Software

The testing of conventional software is often based on coverage criteria defined on the structure of the software. The standard approaches include statement coverage, branch coverage, and data flow coverage. These coverage criteria are based on the control flow diagram or a modified control flow diagram.

Object Oriented Software

Object oriented software adds a new complexity to software testing. The control flow diagram is no longer a good representation of the structure of the software. It would be more appropriate to base structural testing on an object model. However, no effective coverage measures of object models have been found.

The methods in the class should be tested with the techniques already presented. The same coverage criteria can be applied to object oriented software. Intuitively, however, the statement and branch coverage criteria do not seem appropriate for thoroughly testing the complexities of object oriented software. The interactions between methods need to be tested.

One approach to object oriented testing is to cover all the calls to methods. This is sometimes called MM testing.

MM Testing

The MM testing (method message) coverage requires that every method call be tested. Thus, in every method, every call to another method must be tested at least once. If a method calls another method multiple times, each calls needs to be tested only once. This seems to be the most basic coverage criterion. The MM testing does not subsume every statement coverage.

Example :

Identifythe MM testing coverage for the linked list of rectangles problem.
class point {
float x;
float y;
public:
point(float newx, float newy) {x=newx; y=newy;}
getx(){return x;}
gety(){return y;}
};
class rectangle {
point pt1, pt2, pt3, pt4;
public:
rectangle(float pt1x, pt1y, pt2x, pt2y, pt3x, pt3y, pt4x, pt4y)
{ pt1 = new point(pt1x, pt1y); pt2 = new point(pt2x, pt2y);
pt3 = new point(pt3x, pt3y); pt4 = new point(pt4x, pt4y);}
float length(point r, point s){return sqrt((r.getx()-s.getx())^2+
(r.gety()-s.gety())^2); }
float area(){return length(pt1,pt2) * length(pt1,pt3);}
};
class linklistnode {
rectangle* node;
linklistnode* next;
public:
linklistnode(rectangle* newRectangle){node=newRectangle; next=0;}
linklistnode* getNext(){return next;}
rectangle* getRectangle(){return node;}
void setnext(linklistnode* newnext){next=newnext;}
};
class rectanglelist {
linklistnode* top;
public:
rectanglelist(){top = 0;}
void addRectangle(float x1, y1, x2, y2, x3, y3, x4, y4) {
linklistnode* tempLinkListNode; rectangle* tempRectangle;
tempRectangle = new rectangle(x1,y1,x2,y2,x3,y3,x4,y4);
tempLinkListNode = new linkListNode(tempRectangle);
tempLinkListNode->setnext(top);
top=tempLinkListNode; }
float totalArea(){float sum; sum=0; linklistnode* temp; temp=top;
while (temp !=0){sum=sum + temp->getRectangle()->area();
temp=temp->getNext();}
return sum;}
};

The calling structure is shown in the following. For each class, the functions of that class are listed and then for each function that calls other functions, those called functions are listed. For MM testing, everyone of those calls must be executed. For example, four calls to point will be made. No decisions are shown; however, in this program, there are no decisions that affect the calling sequence.

class point
point()
getx()
gety()

class rectangle
rectangle()
point::point()
point::point()
point::point()
point::point()
length()
point::getx()
point::getx()
point::gety()
point::gety()
area()
length()
length()

class linklistnode
linklistnode()
getNext()
getRectangle()
setnext()
class rectanglelist
rectanglelist()
addRectangle()
rectangle::rectangle()
linklistnode::linklistnode()
linklistnode::setnext()
totalArea()
linklistnode::getRectangle()
rectangle::area()
linklistnode::getNext()

MM testing : Anytest case that builds at least one rectangle and then gets the total area will execute all of these calls.

Function Pair Coverage

Function pair coverage requires that for all possible sequences of method executions, those of length two must be tested. This is usually done based on a state machine diagram or on a regular expression showing the possible method executions.

Since a regular expression can be mapped to a finite state machine, these two approaches are equivalent. Although the finite state machine used to describe the behavior of a software system may not be minimal, having additional states will increase the effectiveness of the test set.

class point
point()
getx()
gety()

class rectangle
rectangle()
point()point()point()point()
length()
getx()getx()gety()gety()
area()
length()length()

class linklistnode
linklistnode()
getNext()
getRectangle()
setnext()

class rectanglelist
rectanglelist()
addRectangle()
rectangle()linklistnode()setnext()
totalArea()
(getRectangle()area()getNext())*

Most of the regular expressions for the individual functions have a fixed list of method calls. Onlythe totalArea function is zero or more repetition from the while loop.

Putting all of these together into one regular expression and considering that the rectanglelist has to be created first and then addRectangle or totalArea could be done gives the following regular expression:

rectanglelist ((addRectangle rectangle point point point point
linklistnode setnext) | (totalArea (getRectangle area length getx getx
gety gety length getx getx gety gety getNext)*

The function pair testing can be achieved bythe following test sets: