SOA Testing: Some Assembly Required

Today’s IT departments are using SOA to develop systems composed of many technologies, spread across wide geographies, and that touch all parts of the business. But what best practices should they consider to succeed in delivering SOA-related projects on time? Eric Newcomer, CTO of IONA Technologies, explains.

IT departments are under tremendous pressure to meet the changing needs of business while keeping costs down. A service-oriented architecture (SOA) can help by re-using current investments and allowing organizations to deliver new products and services more quickly all while reducing overall expense.

The adoption of SOA is not without risk, especially when testing and validating the results. In the past, developers delivered complete applications to meet a specific set of predefined business requirements, often without consideration to how other applications were being developed. Instead, SOA development teams must deliver re-usable parts of applications. Distributed development and the shift toward outsourcing can further isolate these teams from each other. All of this changes what needs to be tested and how.

Testing has been primarily a back-end task performed at the end of the development lifecycle. Improved QA techniques, such as test-driven or agile development, promote the preparation of tests from day one of a project. But complete test execution still cannot be performed until the application exists – a sometimes painful limitation that can impact project timelines.

SOA further complicates testing. Limited access to components created by other teams makes unit testing more difficult and less reliable. While each developer follows common specifications, they are subject to interpretation, and service development is often performed in parallel. Serious complications that would have been obvious in the past can remain hidden throughout construction phase. Once the parts are ready, they must be assembled to create the final application. Typically this does not occur until the testing phase. Not only are testers unable to get an early look at a SOA application; they are also now being asked to make room in the testing phase for service assembly.

As a result, serious defects related to system integration are discovered much later in the SOA development lifecycle, when changes are more costly to implement. If organizations are going to be successful with SOA initiatives, this increased complexity needs to be managed so that effective testing can occur earlier in the lifecycle.

We have seen many different approaches to this problem among IONA’s customers. Those most successful have implemented tools and processes that clearly define and validate the correct implementation of the service interfaces. Interface are unlike other SOA application requirements, inasmuch as they are shared and implemented by multiple teams and must match precisely. The slightest incompatibility discovered too late can delay a project weeks or even months.

Testing interfaces early requires more sophisticated tooling than traditional application development environments provide. As a first step, developers often employ homegrown simulators to validate that interfaces are functioning correctly. However, these simulators are typically based on the developer’s interpretation of the specification. Validating the interface against independent tests ensures higher quality. And providing all developers with the ability to validate against the same interpretation of an interface eliminates the potential for unpleasant surprises when the application is finally assembled.

To tackle the problem effectively, development and QA need a shared infrastructure that simulates end-to-end distributed application scenarios and demonstrates how individual components interface with each other in a production environment. Such an infrastructure allows QA and developers alike to test interfaces in a consistent and predictable fashion and enables the detection and repair of defects much earlier in the lifecycle. This approach allows organizations to deliver SOA based projects on time, while reducing the costs and resources dedicated to testing. In short, effective testing during the SOA development lifecycle is a key enabler of SOA benefits.

These are the kinds of challenges that many of IONA’s customers are working through in their SOA deployments today. In the past, testing has been application-centric, but as the testing part of the SOA development lifecycle is adapted more toward individual service and interface testing, the lessons and best-practices these customers are adopting will redefine the meaning of good testing.

Eric Newcomer is Chief Technology Officer of IONA Technologies, responsible for evangelism and for the company’s technical and standards strategy. Eric has nearly 30 years’ experience in a variety of industry and company leadership roles, and has been involved in web services standardization activities from the beginning.