Specifying Distributed Objects

Interface Definition Language

The specification for service providers is usually written in an interface definition language (IDL). Since they are only for specification, the IDLs are simpler than a programming language. The IDL specification provides several pieces of information that are useful for testing purposes:

• signature The main portion of the IDL specification is the usual signature for a method. This includes the name of the method, the types of each of the parameters, and the type of the return object, if any. The standard techniques for sampling values for each of these parameters should be followed in constructing test cases.

• one-way This designation signals an asynchronous message. Testing messages with this attribute requires that the test be conducted over a complete life cycle. There is the possibility that the requester will need the requested information before the provider sends it. There is also the possibility that the message will result in an exception being thrown by the provider. Tests should specifically investigate whether such exceptions are caught in the correct object.

• in, out This attribute of a parameter defines whether the requester is to provide this information or whether it should expect the parameter to be modified by the provider. The tests of a method that specifies an out parameter must locate the returned object (because most object-oriented languages do not handle this case gracefully) and must verify that it has the correct state.

Traditional Pre- and Postconditions and Invariants

We have already presented techniques for building tests from traditional pre- and postconditions, so we will not repeat them here. Distributed components should be designed not to know their location relative to other components; however, the components do have to know about an expanded set of possible errors. The postconditions are expanded to include exceptions for scenarios such as a service that isn't available from the specified provider, a provider that doesn't respond in time, and a requester that provides an invalid address. As with any postcondition, each clause, such as an invalid address, should be covered by a specific test case.

Implicit Tests

Any method that sends a request to invoke a method on a provider may receive a "Provider not found" exception from the infrastructure. Developers are seldom patient enough to write this out as a possible postcondition of every method that causes such an exception to be generated. It is usually the case that there is a set of exceptions that many of the methods in a class may provoke. This is just one example of what we refer to as implicit specifications. These should be matched by implicit test cases. For a distributed system, some appropriate implicit test cases would include the following:

• Test that a requester can handle a "Provider not found" exception.

• Test that a requester can handle a "Provider busy" time-out exception.

• Test that a requester can handle a null provider reference (obviously any null pointer is a problem, but some infrastructures invalidate a pointer after some amount of inactivity).

• Test that a requester can handle a null "out" parameter.

These test cases should be made as general as possible so that it is easy to apply them to each method that fits the implicit specification. The tests should be included in a test checklist for the type of class being constructed.

For each "domain" there is a different list. User-interface objects will have implicit specifications about events and displaying. These should be captured in lists as part of the project test strategy and delivered to the developers and integration testers.