Unit Testing
Unit testing in SOA is not only the testing of components comprising a service, but also the testing of individual services in isolation. This can be done using a static or dynamic client that invokes the service. In this manner, functional and nonfunctional testing on a service can be done. Validity of the content in the request or response can be assessed via XPath or XQuery statements. This is perhaps the easiest of the tests to perform because preexisting Dynamic Invocation Interface (DII) clients are available (java.sun.com/j2ee/1.4/docs/tutorial-update2/doc/JAXRPC5.html).
Integration Testing
Integration testing in SOA is the testing of multiple services in the fulfillment of a use case or business process. Again, challenges arise in transparency within and among services since some of these services can cross organizational boundaries and leverage external systems.
Perhaps the most conceptually straightforward approach to integration testing of SOA is to use service proxies substituting for existing services. This lets the boundaries of the system of interest be simulated. For proxies to deliver meaningful content to these services, realistic data must be obtained. This can be done by monitoring the node that is transmitting the data and copying before sending the data forward. The proxy could then leverage the sample data for testing purposes. One means of generating proxies is to use DII and Dynamic Service Interfaces (DSI) and the interface definition. Pulling previously collected data from a data store provides an approximation of the actual service. A mechanism should be able to toggle between live or simulated data. Similarly, it should be possible to use the proxies to simulate network load and latency.
In addition to proxies, agents can be added to services through plug-in mechanisms. Agents allow monitoring of service inputs and outputs. Additionally, they can be used to monitor various metrics, such as time of processing or network behavior. The granularity of the agent (as a proxy, or else embedded in the service) would allow precise monitoring at multiple levels. If agents possess XPath and XQuery ability, then content validation can be executed too.
Code-Level Change and Instrumentation
When source code is available, test harness frameworks can perform code-level monitoring using utility classes or code instrumentation. One approach to code-level monitoring is to use aspects. In addition to introducing cross-cutting into the source code, aspect frameworks (such as AspectJ) can instrument libraries. Consequently, support for pointcuts and joinpoints can be introduced at a code level as needed. To reduce overhead, the aspect could be written to pass information to a separate monitoring program.
Another useful outcome of such a tool is coverage testing of services in a dynamic service composition environment. This enables an understanding of compositions favored by processes and an insight into which services are used or avoided by user communities.
