A Test Environment

Class Testing

Class testing of distributed components often requires a special environment such as the one illustrated in Figure 8.7. The purpose of this environment is to provide a means of trapping messages to the OUT so that issues such as the timing of messages can be analyzed and changes of state can be logged.

Figure 8.6. The always temporal operator

Figure 8.7. Class testing wrapper

This wrapper is an object that simply encapsulates the OUT. We have used various types of implementations to automatically extract the interface of the OUT and copy it into the wrapper. The wrapper object can be injected into a larger system context and behaves just as the OUT as far as the larger system is concerned. The wrapper has fairly standard implementations of each of the OUT interface methods. Each method does whatever logging is wanted and then forwards the message on to the real implementation in the OUT. The return path will return control to the wrapper. At that time, the method will validate the state in the OUT, log the results, and return the object returned from the OUT.

This approach invades the larger system and is not considered to be testing that context. The objective is testing only the OUT.

This approach is also useful for testing the reordering of asynchronous messages. The wrapper object can simply receive and hold message₁ until message₂ is received. It can then forward message₂ prior to forwarding message₁.

One value of this approach is that it allows complex computations from other parts of the system that would be difficult to provide from a test harness, and allows them to be utilized in testing a class. The wrapper can be built automatically except for the implementation of the OUT methods in the wrapper, but even these use functionality in the wrapper class for logging, checking, and other functionality.

Interaction Testing

Testing the interaction between two objects that are distributed in separate processes from each other uses a configuration such as the one shown in Figure 8.8. As we have previously discussed in Chapter 6, testing a complete protocol is one important aspect of interaction testing. In a distributed system, one of the testing questions that must be addressed is whether messages are really received in that order, even if they are sent in the sequence described by the protocol.

Figure 8.8. An interaction test

In the testing environment shown in Figure 8.8, the presence of a distributed test architecture allows many operations to be done locally. That is, when test driver₁ initiates a test, it informs test driver₂ which test has been executed. Test driver₂ can then verify, on machine₂, that the portion of the test running on machine₂ has been successfully completed. It then informs test driver₁. This greatly reduces the amount of information that must flow from one machine to another and speeds up the testing process.