A Practical Guide to Testing Object-Oriented Software

We now want to discuss testing programs that use some of the standard infrastructures for distributed systems.

Basic Client/Server Model

The client/server model in which multiple clients all have access to the server is the simplest model of distribution. The server is a single process and an indefinite number of client processes can request service from the server. This model has a single point of failure since all of the clients interact with the same server. This model gives a basic idea of a few of the testing issues for distributed systems, but a few systems raise issues that are more difficult than this model.

Testing implications:

1. Can the server deliver correct results to the correct client in the face of a steady load of a moderate number of requests simultaneously over an extended period of time? The server may occasionally send the answer to a request to the incorrect client. This set of tests can be modified to reflect the profile of expected requests in which the number fluctuates with some business cycle.

2. Can the server correctly handle a rapidly increasing load? The server may quickly degrade as the load increases, or it may abort. The test set should present a large number of test cases at increasing arrival rates.

Standard Models of Distribution

The simple client/server model has been generalized to allow the single point of failure of the client/server model to be eliminated. Multiple servers can provide the same service and a client can select which server to use. The early implementations of these models were error prone even in the hands of highly qualified developers because of the primitive pipe and socket structures that had to be manipulated. With the advent of object-oriented techniques, models were developed that abstracted away the networking details and reduced the number of errors. We will not go back and talk about testing the more primitive implementations. We will remain at the object level and assume that a commercial infrastructure is available to hide the communication details.

We will provide just a brief introduction to each of three standard models and then discuss how each supports or facilitates testing systems written using the model. Later, we will discuss the basic infrastructure for Internet applications.

CORBA

The Common Object Request Broker Architecture (CORBA) has been developed by the Object Management Group (OMG) as a standard architecture for distributed object systems. The central element in this architecture is an object request broker (ORB) that one object uses to communicate with other objects in the system. The standard infrastructure provided by a CORBA-compliant system provides services that allow one object to find other objects based on objects being requested, location, or load. The infrastructure also provides services needed to connect two objects written in different languages or objects that are executing on different types of machines. A number of vendors provide products that form the infrastructure for this model. This "standard architecture" does not totally specify an implementation so the software provided by different vendors have competitive differences such as faster throughput and a smaller footprint. CORBA is sufficiently mature so that many of these products have experienced many releases and can be considered "trusted." The CORBA standard is based on the following set of assumptions:

• The machines being linked by the infrastructure may have different operating systems and different memory layout.

• The components that comprise the distributed system may be written in different languages.

• The infrastructure may change its configuration based on the distribution of the objects and the types of machines in the network.

CORBA has the advantage in terms of flexibility. We will focus on this technology in the following examples although the techniques can be applied to the other models with slight modifications.

Testing implications:

• Does the system work correctly regardless of the configuration of the infrastructure? Test plans should provide test cases that result in the expected variety of configurations of the infrastructure being tested.

• Can the test cases be made more reusable by building them based on the services of the standard infrastructure? The infrastructure design is sufficiently mature so that the structure of the test cases should be very stable and the implementation should be mature. The test cases should be designed to use the infrastructure as much as possible.

• Does a specific new release of the infrastructure integrate effectively with existing applications? There should be a regression test suite and test harness that allows new releases of the infrastructure to be tested prior to it being integrated into products.

DCOM

The Distributed Component Object Model (DCOM) is a standard developed and promoted by Microsoft. This infrastructure is freely distributed with the Windows operating system, thus making its cost a clear advantage. The DCOM "standard" is described in terms of standard interfaces containing specific methods rather than architectural generalities. Each standard interface provides a specific set of services. A single component may implement the services of several interfaces or several components may each implement the services of the same interface but in different ways.

The DCOM infrastructure supports the initial connection between components but not as an ongoing part of the application. This reduces the layers through which messages must flow and increases the throughput. However, the standard is largely limited to Intel-compatible machines. This eliminates the need for any type of translation or interfacing services at a cost of the types of systems that can be included in the system. DCOM is a low-level technique that requires an understanding of low-level details and requires the developer to make a number of detailed decisions correctly. Some tools are emerging that automate some of the implementation process and reduce the number of errors.

Testing implications:

• Did the developer correctly align the required unique identifiers at various places in the various components? Test cases should be written to utilize all the various components to ensure that all needed connections can be made.

• Does each component implement the required interfaces? Test cases again should utilize all of the available components to ensure that all services are available and perform the expected functions.

• Do the implementations of the standard interfaces provide the correct behavior? This implies there should be a set of tests defined for each standard interface. That set of tests can be applied to each server that implements the corresponding interface.

RMI

The Remote Method Invocation (RMI) package in Java provides a simplified distributed environment that assumes that no matter what machines or what type of machines are connected, they will all be running a Java virtual machine. This homogeneous environment has a structure that is similar to CORBA but is simpler due to the less flexible assumptions. A registry object is provided and all objects participating in the distributed system must know which port the registry listens to for messages.

The latest version of RMI uses the Internet Inter-Orb Protocol (IIOP) to allow RMI objects and CORBA objects to work together. But more about this in the following general model.

Testing implications:

• Which CORBA test patterns can be used in RMI-based systems? Test cases may be structured the same as many CORBA test cases.

Comparisons and Implications

These three models emphasize the prominent role of interfaces in object-oriented systems in general and distributed systems in particular. Distributed objects advertise services by listing their interfaces with the naming service of the infrastructure. The implication is that functional tests can be organized by interfaces. In particular, in DCOM applications, many classes may implement the same interface and the reuse of the tests for a specific interface will be high.

Distributed object systems are based on a relatively small number of standards. Each model that we have discussed has a more or less formal standard, at least to the extent of standard design patterns. Tests based on these standards have the potential to be reused many times on a single project and across projects in a development organization.