It’s not a novelty that web service compositions have been widely adopted as a convenient mechanism to integrate heterogeneous systems and to model business workflows. Behind the scenes, web service composition development has been a complex activity. From the business side, the third-party service integration assists in the requirements modeling, but this integration is also an issue on the programming side, due to constraints such as absence of testing environment, governance rules, and binding problems. How can you break all of these third-party dependency chains to test web service compositions properly?
A simple but valuable practice in Test-Driven Development (TDD) is the use of mock objects. These controlled pieces of software help the developer narrow the testing scope, deal with tough software dependencies, and keep a testable software architecture. Frameworks such as EasyMock and Mockito have been fluent and intuitive solutions for mocking Java Programs. Given this successful retrospect, why not utilize these concepts to deal with the aforementioned web service composition development problems?
An alternative for mocking web services
This post presents the service mocking feature of Rehearsal, a framework that brings features to promote agile testing in web service compositions. This feature consists of an abstraction of the soapUI mocking. In contrast to this tool, Rehearsal provides a fluent interface that aims at providing mechanisms similar to Mockito or EasyMock in web services. As a result, mocking a SOAP web service is similar to mocking a Java program.
The first step to mock a web service operation using Rehearsal is to select which web service requests will be mocked. To avoid XML manipulation, Rehearsal provides the Item object, a recursive data structure that represents web service requests and responses:
In Figure 1 (above), a simple XML request is mapped into an Item object. Using Rehearsal, the same can be done to an XML response. Suppose we want to mock the requestNewProduct operation, we can start by publishing our mock service:
String wsdlUrl = “http://www.sportTown.com.br/wsdl”;
WSMock mock = new WSMock("sportTownMock", wsdlUrl, "9000");
At this point, a mocked service will be publish on the port 9000 of a localhost jetty server instance. Then, let’s configure the mock responses:
Item confMessage = new ItemImpl("message");
Item errorMessage = new ItemImpl("message");
errorMessage.setContent("ERROR: Product already registered");
MockResponse response =
MockResponse response1 =
mock.returnFor(“registerNewProduct”, response, response1);
In this simple example we adjusted the mock to return two different responses for the registerNewProduct operation. In the first response, this operation will return the errorMessage Item when receiving as a request the product Item object which is presented in Figure 1. Otherwise, for any other received request that does not match this product Item, our mock will return a confirmation message to indicate the correct product creation.
During system integration, aside from testing the regular behavior, faulty third-party scenarios must also be assessed. To help the developer in one more tough task, WSMock provides features to simulate absence and delay of responses as well as crashing behavior.
With the doNotResponse method, we can emulate an absence of response. With WSMock, we can also configure a message delay. Besides that, it’s possible to simulate a crash behavior in the mock.crash call. In the web service composition context, it is important to test and cover the faulty scenarios to aggregate more robustness to the application.
Know more about it …
Aside from the WSMock, the Rehearsal framework provides features designed to help the developer create web service clients (WSClient) and intercept messages in a composition (message interceptor). These features have been created to facilitate web service development, and then, aggregate more importance to the developer role in the life cycle of SOC (Service Oriented Computing) applications. Rehearsal is an open source project, under the LGPL license, and is available through this page. The project is supported by HP Labs, the CHOReOS EC FP7 Project, and the University of São Paulo and new features and improvements will be added within the coming months.
Felipe Besson has Masters in Computer Science for the University of São Paulo (Institute of Mathematics and Statistics), Brazil. His research focused on automated testing of distributed components such as web services composition. He is also a software developer in Elo7, a marketplace for artisans and lovers of handcraft and handmade goods in Brazil.