Web Service Validation Enabling Test-Driven Development of Service-Oriented Applications

Posted on by : admin Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Test-Driven Development (TDD) is an important software development practice that enables rapid iterations, refactoring, and improved quality. Supporting TDD can be difficult when building Service-Oriented Architecture (SOA) applications, since standard test frameworks often do not have capabilities for performing and validating Web service (WS) calls; invoking Web services depends on running and connecting to a service container; and services and clients often have entirely separate implementations.

In this paper we present case studies of two SOA applications we developed, GRIDL[1] and TxFlow. These are distributed, multi-language applications using Web services as the interface between service and client components. They implement Web service and client tests both for verification and validation of the application components and to facilitate the TDD process. Our approach to Web service testing to support TDD is easily reproducible in any SOA application without requiring significant development effort or changes to the software design.

Development tools are beginning to recognize the importance of Web service testing by providing built-in support and automation. For example, the Grails[12] Web application framework for the Groovy language enables service testing by automatically generating JUnit-based test stubs and mock service interfaces that minimize the effort of TxFlow Client flow.xml TxFlow Service Test Client Flow DB Grid process process process process Flow Runner Internet creates creates submits submits writing service tests. Numerous Web service testing tools exist. Most of these are intended for remote testing of live services to establish characteristics such as Quality of Service (QoS), Service Level Agreement (SLA) compliance, or standards compliance, rather than being intended for fine-grained, developer-defined tests of specific service behaviors as required to support TDD.

The following paragraph describes a representative sample of such Web service testing tools. Coyote[13] is a framework for testing SOA applications which generates and runs test cases based on WSDL files and a graph describing the application components. The Web Service Interoperability (WS-I) Organization’s Testing Tools[14] monitor Web service messages and validate their conformance to WS-I interoperability guidelines. WebServiceTester[15] is an integrated suite for functionality, performance, and regression testing of Web services.

It provides automated test data generation and test service orchestration based on Business Process Execution Language (BPEL). SOAPScope[16] tests SOAP transactions by monitoring communications between endpoints and examining WSDL and SOAP messages. SOA Test[17] offers WSDL validation and functionality and performance testing.

Based on our experiences from GRIDL and TxFlow, we conclude that Web service tests are critical to facilitating TDD for SOA applications. Such testing also has important benefits both in validating code in distributed systems’ components and interfaces and in ensuring the expected operation of Web services.

Our general approach of making tests act as clients that connect to the service container to invoke Web service methods and validate their behaviors is applicable to any SOA application.

This approach has many advantages. It not only automates validation of distributed application components’ interfaces, but enables testing of service behavior that is difficult to elicit otherwise, such as error handling, multiple connections, asynchronous operations, and stress testing. For these reasons, we expect to see increasing support in software development and integration tools for WS verification and validation using similar models to ours