Supporting Test-Driven Development of Web Service Choreographies

1. Felipe Besson, Pedro Leal, Fabio Konand Alfredo Goldman {besson, pedrombl, fabio.kon, gold}@ime.usp.br Departmentof Computer Science - IME - Universityof São Paulo DejaMilojicic - dejan@hpl.hp.com Hewlett Packard Laboratories OurPrototype Introduction AcceptanceTesting The choreography is tested from the user perspective. In this context, the choreography is accessible as an atomic service, and each test exercises an entire conversation as a unit. Before the acceptance testing execution, the prototype deploys and enacts the choreography in a distributed environment. Web service choreographies have been proposed as a decentralized, scalable way of composing services. This work represents our first efforts to achieve our goals. Our prototype consists of: • Ad hoc bash scripts for the Book Trip choreography deployment and enactment on a distributed environment (using OpenKnowledge[4]); • A set of JUnit test cases for automated testing of this choreography (see the tests below); Inherent characteristics of Service-Oriented Architecture (SOA) such as dynamicity, lack of observability of the service code and structure, difficulties in interoperability,and third party participants makes traditional testing techniques inappropriate [1]. The stepsoftesting IntegrationTesting Goals Developer activates the choreography, invoking service A; Messages are exchanged between services A and B; Output messages from B are intercepted; Messages are stored in a queue; Collected data is validated. We aim to develop a testing framework for supporting Test-Driven Development (TDD) [2] of choreographies. During the development, the framework will provide features for automated testing of: • Isolated services; • Messages exchanged within the choreography; • The entire choreography. Also, the testing framework shall provide mechanisms for enacting (starting) and stopping the choreography automatically on a cloud environment, e.g., Open Cirrus or Amazon EC2 Supporting Test-Driven Development of Web Service Choreographies each service messages exchanged entire choreography Unit Testing Every operation of each service participating in the choreography is tested: class TravelAgencyWSTest { BASE_URL = “localhost:9881/travelagency”; private RESTClient client; @BeforeClass public static void publishWS() { Bash.deployService(“travelAgency”); client = new RESTClient(); client.setBaseURL(BASE_URL);} … @Test public void shouldRetriveCreditCardNumber() { body = “John|421543-2”; client.POST(“/users”, body); response = client.GET(“/users?name=John”); assertEquals(“421543-2”, response); } … class AirlineWSTest { private AirlineWSClient stub; @BeforeClass public static void publishWS() { Bash.deployService(“airline”); } … @Test public void shouldFindFlight() { flight = airlineWS.getFlight(“Moscow”, …); assertEquals(“3810”, flight.getId()); assertEquals(“Moscow”, flight.getDest()); assertEquals(“06-01-11”, flight.getDate()); assertEquals(“09:15”, flight.getTime()); } … Code Example Testing code of example above: AStub.sendMessageToC(“x”, “Hello!”); String actualContent = queue.get(“B”, “C”, “x’”); assertEquals(“Hello!”, actualContent); REST Service SOAP Service Book TripChoreography Integration Test Example This example shows a situation where only integration tests would find the bug in the system. In this case, the acquirer service only works with dollar amounts. When it receives the message with the content in the Brazilian currency, it mistakenly interprets the value as dollar. A global view of a choreography in BPMN2 [3] for planning and booking a trip. Global View Overhead Evaluation The integration testing approach must collect the messages exchanged among the services. Such procedure might cause an overhead in the choreography execution. Here, we present a quantitative assessment to evaluate possible overheads: • We compared the execution time of a choreography functionality using and not using our approach • We used a simple interaction operation (orderTrip operation with 4 messages exchanged) • It was executed in a cluster. Each web service was allocated on a dedicated node • Execution time for 1, 2, 4, 8, and 16 sequential executions • 30 samples for each one Results Integration testing code that discover the error above: travelerStub.bookReserve(reserve); String expected = queue.get(“airline”, “travelagency”, “value_paid”); assertEquals(“BRL 2000”, expected); Ongoingwork We are extending our prototype by providing features for: • Generating web service clients dynamically; • Manipulating the elements (roles, messages, services) of a choreography more easily; • Mocking third-party services and choreography parts; • Improving the interception and validation of exchanged messages. • Automating the deployment and enactment of choreographies on a cloud environment The overhead is smaller than the standard deviation (between parentheses). Thus, the overhead is negligible. Since we do not net need to store the entire XML-Soap message but only its content, the message monitoring process is relatively fast. More information: http://ccsl.ime.usp.br/baile/VandV Acknowledgments References This research is funded by: [1] G. Canfora and M. Di Penta. Service-oriented architectures testing: A survey. In A. De Lucia and F. Ferrucci, editors, Software Engineering, volume 5413 of LNCS, pages 78–105. Springer, 2009. [2] Kent Beck. Test Driven Development: By Example. Addison-Wesley Professional, 2002.[3] OMG. Business Process Model and Notation. Available on: http://www.bpmn.org/.[4] OpenKnowledge Project. Available on: http://www.openk.org/