I’ve found soapUI a valuable tool when working with web services. I previously wrote about how to get started and some test case basics here, here and here. I just want to add a few more tips I that took me a little bit of trying and reading to figure out:

Web Service Bindings

• Change or update the wsdl for a binding by right-clicking on it and selecting “Update Binding”.
• Double-click on the binding to open its properties. Here you can add more endpoints (urls pointing to other instances of the same web service) and assign them to requests. This is useful if we for example wanted to build the test suite against our development instance but then run the actual load test against a special test setup. In this window, you also can test your service for WSI-compliance.
• Add another binding by right-clicking the project and selecting “Add WSDL”.
• When having troubles with the WSDL import (especially if complex types are used by the service), try saving the wsdl to the file system and pointing the “Add WSDL” dialog to the file rather than using the “?wsdl” option on the live web service. The bindings endpoints may have to be updated afterwards (see above).

Load Tests
Once you have Test Suites like I’ve shown in the previous examples, you can use them to run load tests. Simply add a Load Test to the Test Suite via the context menu. This will open the Load Test screen where you can start your load test immediately.

Finally: For more details and ideas, look at the soapUI documentation at http://www.soapui.org/userguide/index.html.

Anke

If you missed the first two parts of this series, you may want to check them out first here and here. Today I want to show a few more enhancements to make a test case more flexible. We’ll be using the simple add method of the Arithmatics service to calculate the beginning of the Fibonacci Sequence (Wikipedia).

The screenshot below shows the initial Test Case setup: I added two properties, Number1 and Number2, and initialized them to the start values of the Fibonacci series (0 and 1). There is also the first addition step (in this case we won’t loop over the step but add a new step for each addition. Looping has to be scripted in the Open Source edition of soapUI).

1. Before the “Add 1″ request step, insert a Groovy Script step to initialize the properties. Since we’ll change them during the test, we need to make sure they have the correct values. Groovy uses a Java-like syntax.
   

   def tc = testRunner.testCase;
   //Get a handle for the test case object
   def tc = testRunner.testCase;
   
   //Reset "Number1" to 0
   tc.setPropertyValue("Number1",  "0");
   
   //This is just to show how to log and assert property values
   def num1 = tc.getProperty("Number1").value;
   log.info("Number1 was set to " + num1);
   assert num1 == "0" : "Updating Number1 failed";
   
   //Reset "Number2" to 1
   tc.setPropertyValue("Number2",  "1");

2. After the “Add 1″ Step, add another Groovy Script step to update the Number1 and Number2 properties with their new values. The script:
   

   def tc = testRunner.testCase;
   def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
   
   // create holder for the response of "Add 1" Test Step
   def holder = groovyUtils.getXmlHolder( "Add 1#Response" );
   
   // register the namespace (needed for XPath expression below)
   holder.namespaces["qat"] = 'http://math.qat.com/';
   
   //Get handle for test case
   def tc = testRunner.testCase;
   
   //Set Number1 to current value of Number2
   tc.setPropertyValue("Number1",  tc.getPropertyValue("Number2"));
   assert tc.getProperty("Number1").value == "1" : "Updating Number1 failed";
   
   // Set Number2 to the result of the "Add 1" Request
   log.info(holder.getNodeValue('//qat:addReturn'));
   tc.setPropertyValue("Number2",  holder.getNodeValue('//qat:addReturn'));
   assert tc.getProperty("Number2").value == "1" : "Updating Number2 failed";

   Tip: When editing properties like that, it may be better to test the script by running the whole test case or temporarily add a section to initialize the properties to the expected values to guarantee that the properties are in the right state.

3. Clone the “Add 1″ Test Step (”Clone Test Step” from context menu) twice to “Add 2″ and “Add 3″. XPath assertions for the result value need to be updated to 2 and 3, respectively. The steps are inserted at the end of the Test Case.
4. Add another Groovy Script step (”Update Properties 2″) between “Add 2″ and “Add 3″. This time we’ll retrieve the values for the “Add 3″ request from the results of the “Add 1″ and “Add 2″ requests and insert them directly in the XML for “Add 3″:
   

   def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
   
   // create holder for response of "Add 1" to obtain first operand
   def holder = groovyUtils.getXmlHolder( "Add 1#Response" )
   // register namespace
   holder.namespaces["qat"] = "http://math.qat.com/"
   def num1 = holder.getNodeValue( "//qat:addReturn" )
   assert num1 == "1" : "Retrieving 'Add 1' result failed"
   
   // create holder for response of "Add 2" to obtain second operand
   holder = groovyUtils.getXmlHolder( "Add 2#Response" )
   holder.namespaces["qat"] = "http://math.qat.com/"
   def num2 = holder.getNodeValue( "//qat:addReturn" )
   assert num2 == "2" : "Retrieving 'Add 2' result failed"
   
   // create holder for request of "Add 3" and set operands
   holder = groovyUtils.getXmlHolder( "Add 3#Request" )
   holder.namespaces["qat"] = "http://math.qat.com/"
   holder.setNodeValue( "//qat:number1", num1 )
   holder.setNodeValue( "//qat:number2", num2 )
   
   // update "Add 3" request
   holder.updateProperty()

5. Open the Test Case and run it.
   

Of course, there are lot more efficient strategies to set up this particular scenario than shown here, especially in soapUI Pro. I just wanted to show a few options for passing properties from one request to the next to build a more complex test case where the next request depends on the outcome of a previous call.

Anke