Cloud Computing and SOA Convergence in Your Enterprise: A Step ...

Testing from the Enterprise to the Clouds and Back 169
logical service. In some cases, we may be testing a service that calls a service
that calls a service, where some of the services are developed and
managed in-house and some exist on cloud-based systems that we do
not control. All use cases and configurations must be considered.
Services should be tested with a high degree of autonomy. They should execute
without dependencies, if at all possible, and be tested as independent
units of code using a single design pattern that fits within other
systems that use many design patterns. While all services cannot be all
things to all containers, it is important to spend time understanding
their foreseeable use and make sure those are built into the test cases.
Services should have the appropriate granularity. Do not focus on toofine-grained
or too-coarse-grained services. Focus on the correct granularity
for the purpose and use within the SOA using cloud computing.
The issues related to testing are along the lines of performance more
than anything else. Too-fine-grained services have a tendency to bog
down because of the communications overhead required when dealing
with so many services. Too-coarse-grained services do not provide the
proper values to support their reuse. We must work with the service designer
as well as developers on this one.
What do we test for within services It is important to follow a few basic
principles.
First, 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 are not 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 have
used for most of their careers. Thus, the patterns must be applicable to more
than a single problem domain, application, or standard, meaning we must
have use for our reusable service, and it must be in good working order.
To test for reusability, we create a list of candidate uses for the service—
for instance, a shipping service that plugs into accounting, inventory, and
sales systems (see Figure 9.2). Then, the service should be consumed by the
client, through either 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 there are no calls to native interfaces or platforms.