SOAP Tutorial 4 – API Workflow Simulation and Testing

When it comes to web services API testing in a very simplistic view, folks are divided into two different groups. One group of users is interested in simply having something to invoke the service, primarily for debugging purposes. The other group of users however is interested in more sophisticated and robust validation of API’s functionality. Crosscheck Networks focus is on Enterprise Level tools for insuring high quality of the end product – Robust and Sustainable API.

One of the fundamental benefits of a web services-based API is reuse and componentization. One web services call may however depend on the response from another. The result is a meshed or chained set of interdependent operations called in sequence. Automated testing requires test cases to be built, linking these chained services.

In tutorial #2 – Functional Testing, we looked at how functional testing of a single Web Services API. In this tutorial, we look at chaining these into a Automated test case using workflow simulation. A common example of a multi-step process would be:

1. Login

2. Create Customer Record

3. Assign product to a client

4. etc etc etc

5. Logout

Here the services must be chained and information from one service must be passed to the next in order to simulate a complete workflow. SOAPSonar is capable of simulating of complex workflows without any scripting or coding. Saving the automated test case, that then requires very little maintenance as new releases become available.

The web service that we will use is hosted by http://www.w3schools.com and is called Temperature Convert. NOTE: This is a SOAP based service. The process of chaining two REST services or ESB based service etc. is much the same. We will chain two requests, passing response from the first call to the second.

1. First, we need to capture the WSDL of the service to determine what operations are exposed by the service.

3. We are ready to submit our FahrenheitToCelsius request. Select SEND CURRENT REQUEST TO SERVER.

4. Now we need to capture result returned by FahrenheitToCelsius and store in a variable. This variable will be used to pass the value to the next operation in the chain. Execute the operation and save the value. In the Response Panel, select the RUNTIME VARIABLES Tab as shown below.

5. Right click on the FahrenheitToCelsiusResult value 37.77777777 and select the Add Variable Reference. Confirm the name and select OK. You should see a Variable Name $rv:FahrenheitToCelsius_1 : Element : FahrenheitToCelsiusResult$ and a Capture Element appears in the Variable Reference(1) Tab.

10. Select SEND CURRENT REQUEST TO SERVER Executing the CelsiusToFahrenheit test results in the FahrenheitToCelsiustest case Response Value being evaluated and sent as an input to CelsiusToFahrenheit with the following result converting back to 100

11. Now to view your automated chained test case visually, go to Run View and drag and drop CelsiusToFahrenheit test case (only) into DefaultGroup. Expanding tree view, you will see that SOAPSonar automatically recognized that FahrenheitToCelsiustest Test Case is a prerequisite to CelsiusToFahrenheit and must be run first, as part of the automated test.

12. Select RUN SUITE. The ANALYZE RESULTS IN REPORT VIEWwill show the sequence of the call as well as the response times for each step in the chained link

13) Save the project and name it.

You know know how to use SOAPSonar to chain the response from one API service and use that response as the input for a second service. Could you do this with a Automated data source and success criteria?