Unit, integration testing first steps toward SOA quality

The unit testing challenge with SOA is not so much the actual exercise of unit testing but the speed at which it has to occur.
The service-orientated architecture (SOA) paradigm endeavors to address both the time-to-market challenge faced by business and the need for IT to develop, test, and deploy ever-evolving, complex solutions. SOA breaks complex solutions into component parts (services) that present a simple interface to the application landscape while encapsulating both data and process. These services can be provided in-house, by business partners, and by commercial services.
From a testing perspective, the most significant challenges presented by SOA are the fact that SOA application landscapes are "always on," are continuously changing, are loosely coupled, and usually involve multiple providers (in-house, business partners, and commercial services). Finally the quality of the individual services does not necessarily translate into the overall quality of the business solution -- it is the quality of the whole that truly matters.
Example of an SOA application landscape
Let's look at a simple and rather "coarse" (large complex services) example of an SOA application landscape. In this case, the SOA solution addresses the need to sell digital media online. Service layers consist of a Web-enabled presentation layer, customer account service, catalogue service, cart service, digital fulfillment service, customer history service, and an accounting service that interfaces to a standard financial services database. The following figure illustrates this SOA solution.
From a unit and integration testing perspective we will focus on the "cart service" and its relationship to the presentation layer and immediate service partners. We will later extend this model to address a single business event (customer purchase) in a follow-on article on SOA functional and regression testing. The following figure illustrates the relationship of the cart service to its immediate service partners.
The cart service is loosely coupled to the catalogue, customer history, and digital fulfillment services with a tight coupling to the Web-enabled presentation layer.
SOA -- Unit & integration testing
SOA promotes reuse at the service level rather than at the code/objects level. If you think of each component truly as a service, then there are internal aspects (data and process) and external facing (interface) aspects of the service that need to be tested.
It is convenient to think of the internal aspects of the service in terms of unit testing and to think of testing interface relationships with immediate service partners in terms of integration. It should be noted that unit and integration testing is often ignored or given minimal attention in traditional development environments -- the assumption being that downstream testing will catch any errors before the product reaches production. That is not the case in the world of SOA, where the eventual applications of a service could and often are beyond the control of the development group. Demonstrated adherence to the service design and interface specification is one way to reduce the impact of unexpected downstream implementations of the service.
Unit testing: The process of testing the individual servicesUnit testing of a service should be performed by the developer and should be reviewed by development peers. At a minimum unit testing should consist of both verification of the unit (service) design and validation of the unit (service) implementation.
The purpose of unit testing is to discover and address discrepancies between the specification and implementation. This is especially important when implementing SOA because services are often developed in parallel and undergo continuous development/deployment. That means adherence to design specifications and the ability to effectively encapsulate a service is critical to meeting the contractual obligations of the service. The developer or development organization will have to create stubs to test the interfaces the service supports. This becomes critical once development moves towards integration testing.
The unit testing challenge with SOA is not so much the actual exercise of unit testing but the speed at which it has to occur. There are several well-documented approaches to development and unit testing that will address this challenge, but one that is not often mentioned is the application of Agile development techniques in combination with instrumentation of the code to support continuous integration. Using methodologies and technologies that enable this approach helps address the challenges of continuous development/deployment that are a landmark characteristics of the SOA application landscape.
One other aspect of the SOA application landscape that will impact how unit testing is approached is the extent to which in-house developed and deployed services are employed. The more "in-house" the SOA solution is, the more it can be treated as a component-based solution. Basically that means the pace and extent of any changes are within the control of the development organization.
Integration testing: The process of testing integrated servicesIntegration testing of a service should be performed by the QA/testing team and reviewed by both the architecture lead and development leads. At a minimum integration testing should consist of both verification of the integrated architectural design as it relates to the service under test and validation of integrated services. For each service this would consist of testing the functionality of the service and its relationship with all immediate (directly connected) services.
In our example, integration testing of the cart service would involve testing the cart service functionality and the integration of that service to the catalogue service, customer history service, digital fulfillment service, and the Web-enabled presentation layer. The purpose is to discover and address discrepancies between the functional specification and implementation of the cart service and its contractual responsibilities with other (immediate) services. Once again, this is especially important when implementing SOA.
The integration testing effort should focus on the service undergoing integration testing and its contractual responsibilities with other (immediate) services. There are several reasons for taking this approach, not the least of which is that integration testing of SOA solutions is extremely challenging -- the wider the scope of the integration testing effort, the more challenging it becomes. It useful to focus on the immediate landscape to ensure the contractual obligations are being met by each service and then extend the scope of testing during functional testing. The basic premise is to treat the services as building blocks that compose/support a particular business event or part of an event.
There are several automated SOA testing tools available (commercial and shareware) that help address the testing of services, and there are more traditional testing tools that can be tooled to address SOA testing. Many are able to capture service descriptions and create initial tests based on these descriptions. Those tests can then be automated.
Once you've completed integration testing of closely related services, you can begin true functional testing. This is where the real challenges of testing SOA solutions come to bear and involve the following:
· Third-party services
· Late binding (selection of service)
· Missing/incomplete/changing services
· Multi-platform/Multi-language distributed services

By David W. Johnson