How to design a test case for an inter-class?

As the integration of object oriented system begins, the designing of test cases becomes difficult. Testing of collaborations among classes should start at this point. It can be accomplished by applying random and partitioning methods and also scenario based and behavioral testing.

Multiple class random test cases can be generated in following steps:
- Generate random test sequences from the list of class operations for each client class and these messages are sent to server classes.
- Collaborator class and the operation is determined for each message that is generated.
- The transmitted messages are determined for each operation in the server object.
- The next level of operations are determined for each of the messages.

A state diagram for a class is used to help in deriving a sequence of tests that exercises the dynamic behavior and the classes that are collaborated with it. The tests that are designed should achieve all state coverage. Every behavior for the class should be adequately exercised. In case of inter class test case design, multiple state diagrams are used to track the behavioral flow of the system.

A state diagram can be traversed in a breadth first manner. It implies that a test case exercises a single transition. When a new transition is to be tested only previously tested transitions are used.

Introduction to Object Oriented Testing Methods

Object oriented testing begins in the small with a series of tests designed to exercise class operations and check whether errors exist as one class collaborates with other classes. Use based testing along with fault based testing is applied to integrated classes. In the end, use cases are used to uncover errors at software validation level.

Encapsulation can create a minor problem when testing because testing reports on concrete and abstract state of an object. Multiple inheritance complicates testing by increasing number of contexts for which testing is required. Black box testing methods are appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

The strategy for fault based testing is to hypothesize a set of possible faults and then derive the tests to prove each of that hypothesis. The effectiveness of these techniques depends on how testers see a plausible fault.

Inheritance complicates the testing process. even though the base class has been properly tested, there is a need to test all classes derived from it.

Scenario based testing will uncover errors that occur when any actor interacts with the software. It concentrates on what the user does and not what the product does. This type of testing uncovers interaction errors.

Surface structure is an externally observable structure of object oriented program. Testing surface structure is similar to black box testing. Deep structure refers to the internal technical details of object oriented program. It exercises dependencies, behaviors and communication mechanisms. It is similar to white box testing.

Object Oriented Software and its Test Strategies...

In testing object oriented software, the objective of testing remains the same. The nature of object oriented software changes both testing strategy and testing tactics.

UNIT TESTING IN OBJECT ORIENTED CONTEXT
In object oriented software, an encapsulated class is the focus of unit testing. Encapsulation means that class and class object packages the attributes and operations that manipulate the data. A class contains many operations so unit testing these operations must also vary.
Class testing for object oriented software is analogous to module testing for conventional software. It is not advisable to test operations in isolation. Unit testing of conventional software focus on algorithmic detail of module and the data that flows across module whereas unit testing for object oriented software focus on operations encapsulated by class.

INTEGRATION TESTING IN OBJECT ORIENTED CONTEXT
An important strategy for integration testing of object oriented software is thread based testing. Threads are set of classes that respond to an input or event. Each thread is integrated and tested individually. Regression testing is done.
Another strategy is the use based tests that focus on classes that do not collaborate heavily with other classes.

The behavior of drivers and stubs also changes during integration testing of object oriented software. Drivers test operations at lowest level and for testing whole group of classes. Stubs are used where collaboration between classes is required but one or more collaborating class is not fully implemented.