Traditional testing techniques assume defective code can be precisely determined. But this isn't always the case when Service-Oriented Architectures (SOAs) are involved. SOA implies a network of distributed nodes, some of which may be clustered, redundant, or maintained by other organizations. Consequently, isolating problems in a system can be demanding. Also, SOA systems tend to be always online, even when new services are introduced to or removed from live systems.
For these reasons, SOA testing presents a level of opacity that more traditional systems avoid. To address these problems, SOA testing must leverage best practices from existing testing methodologies and create new approaches. In this article, I discuss SOA testing and present a SOA test harness.
SOA Testing
In testing SOA, traditional test practices should not be abandoned. But because of SOA's distributed and technologically heterogeneous nature, testing best practices need to be extended. As with non-SOA code, unit testing of a service is a necessary first step, offering the first line of defense against defects in implementing services. Likewise, integration testing is a necessity as service choreography and orchestration become the means to support business processes. In the world of SOA integration testing, services may be provided without code from other groups or hosted outside of the testing environment.
With this in mind, it becomes increasingly apparent that what is required for testing in SOA environments is the ability to monitor the inputs and outputs of each service, validate data at each node, and assess the behavior of each node under different loads and constraints. As the number of services grow, it becomes essential to monitor the relevant services of a business process or use case in a controlled manner.
One solution to this problem assumes that an Enterprise Service Bus is used and can emit debugging and auditing information as messages pass through (www.crosschecknet.com/soa_testing/TestingInAServiceOrientedWorld.pdf). While useful, this approach often lacks the granularity necessary in debugging complex applications. Another potentially more complete solution to the problem is to isolate the services of interest within a harness that simulates the behavior of the system at the boundaries, then monitor each service in the system.
