What’s Neglected When Testing Services?

People are forgetting a few things when testing services.

First and foremost, services should be tested for reuse (reusability). Services become a part of any number of other applications, and thus must be tested so they properly provide behavior and information, but not be application or technology specific. This is a difficult paradigm for many developers since custom one-off software that digs deeply into native features is what they’ve been doing for most of their careers. Thus, the patterns must be applicable to more than a single problem domain, or application, or standard, meaning you must have use for your reusable service and it must be in good working order.

To test for reusability you must create a list of candidate uses for the service. For instance, a shipping service that plugs into accounting, inventory, and sales systems. Then, the service should be consumed by the client, either through a real application (in a testing domain) or a simulator, and the results noted.

In addition, the service should be tested for heterogeneity. Web services should be built and tested so that there are no calls to native interfaces or platforms. This is due to the fact that a service, say, one built on Linux, may be leveraged by applications on Windows, Macs, and even mainframes. Those that leverage your service should do so without regard for how it was created, and should be completely platform independent. The approach to testing this is rather obvious; simply consume the service on several different platforms, and note any calls to the native subsystems.

You should also test for abstraction. Abstraction allows access to services from multiple, simultaneous consumers; hiding technology details from the service developer. The use of abstraction is required to get around the many protocols, data access layers, and even security mechanisms that may be in place, thus hiding these very different technologies behind a layer that can emulate a single layer of abstraction.

Abstraction is tested effectively by doing, which means implementing instances and then testing the results. Regression and integration testing is the best approach, from the highest to the lowest layers of abstraction.

When we build or design services we need to test for aggregation. Many services will become parts of other services, and thus composite services leveraged by an application. You must consider this in their design. For instance, a customer validation service may be part of a customer processing service, which is part of the inventory control systems. Aggregations are clusters of services bound together to create a solution, and should be tested holistically through integration testing procedures.