A software typically undergoes many levels of testing, from unit testing to system or acceptance testing. Typically, in unit testing small “units”, or modules of the software are tested separately with focus on testing the code of that module. In higher, order testing (e.g., acceptance testing), the entire system (or a subsystem) is tested with the focus on testing the functionality or external behavior of system.

As information systems are becoming more complex, object-oriented (OO) parading is gaining popularity because of its benefits in analysis, design and coding. Conventional testing methods discussed in the chapter cannot be applied for testing classes because of problems involved in testing classes, abstract classes, inheritance, dynamic binding, message, passing polymorphism, concurrency etc.

Testing classes is a fundamentally different problem then testing functions. A s a function (or a procedure) has a clearly defined input-output behavior, while a class does not have an input-output behavior specification. We can test a method of class using approaches for testing function, but we cannot test the class using these approaches.

According to (Davis 98) the dependencies occurring in conventional systems are:
•    Data dependencies between variables
•    Calling dependencies between modules
•    Functional dependencies between a module and the variable it computes
•    Definitional dependencies between a variable and its types.

But in OO system there are following additional dependencies gives by (Norman 92) :
•    Class to class dependencies
•    Class to method dependencies
•    Class to message dependencies
•    Class to variable dependencies
•    Method to variable dependencies
•    Method to message dependencies
•    Method to method dependencies

Additional testing techniques are therefore, required to test these dependencies. Another issue of interest is that it is not possible to test the class dynamically, only its instances i.e., objects can be tested. Similarly concept of inheritance opens various issues e.g., if changes re made to apparent class or super class, in a larger system of a class it will be difficult to test subclasses individually and isolate error to one class.

In object-oriented programs, control flow is characterized by message passing among objects, and the control flow switches from one object to another by inter-object communication. Consequently, there is no control flow within a class like functions. This lack of sequential control flow within a class requires different approaches for testing. Furthermore, in a function, arguments passed to the function with global data determined the past of exculpation within the procedure,. But,  in an object, the state associated with object also influences the path of execution, and methods of a class can communicate among themselves through this state,  because this state is persistence across invocations of methods. Hence, for testing objects, the state of an object has to play an important role.

Overall, testing of objects can be defined as the process of exercising the routines provided by an object with the goal of uncovering errors in the implementation of the routines or state of the object or both. To test an object, we have to test the interactions be viewed as a search problem for finding the patters of method invocation of the object under test with different arguments, which will yield errors. This is particularly important as there is no order imposed on the invocation of the methods of the objects we are testing the communication between the different methods of the object. Directly testing various patterns of method invocation was the approach used in for testing abstract data types.

This type of testing allows for designing test cases based on the client specification or the code or both. It tries to identify possible faults (areas of design or code that may lead to errors). For each of these faults a test case is developed to “flush” the errors out. These tests also force each time of code to be executed.

This method of testing does not find all types of errors. However, incorrect specification and interface errors can be missed. These types of errors can be uncovered by function testing in the traditional testing model. In OO model, interaction errors can be uncovered by scenario-based testing. This for of OO-testing can only test against the client’s specification, so interface errors are still missed.

This approach is the simplest approach to test classes. Each method of the class performs a well defined cohesive function and can therefore be related to unit testing of the traditional testing techniques. Therefore all the methods of a class can be involved at least once to test the class.

This is one of methods used to exercise a class. It is based on developing a random test sequence that tries the minimum number of operations typical to the behavior of the class

This method categorizes the inputs and outputs of a class in order to test them separately. This minimizes the number of cases that have to be designed. To determine the different categories to test, partitioning can be broken down as follows:

•    State-based partitioning – categorizes class operations based on how they change the state of a class.

•    Attribute-based partitioning – categorizes class operations bases on attributes they use.

•    Category-based partitioning- categorizes class operations based on the generic function the operations perform.