SoapUI 3.0 comes with support for creating web service tests. This is quite easy to do once you understand the concepts.

The first step is to start with an existing SoapUI project. Define the web service calls you’ll be making. The easiest path is simply to import some existing WSDL.

Once you have the web services defined, make some test calls to ensure the web service definitions are working. Fix any issues you find before continuing.

Now comes the interesting part. Create a new test suite. Right click on the SoapUI project and choose the ‘New TestSuite’ option. Give it a name and choose OK.

The new test suite window will automatically appear. A test suite is a collection of test cases. Each test case is composed of one or more steps. The test suite window is where you create the test cases.

Click on the check mark icon to create a test case.

You can also right click on the test suite in the navigator and choose ‘New TestCase’. The test case editor window will automatically open.

A test case is made up of multiple test steps. Each test step can be a web service call, REST call, HTTP call, mock response or a processing step: a Groovy script, a properties step, a property transfer, conditional goto, delay, or other test case.

Information is passed between test steps as properties. You can load properties from a file using a properties step or pre-define them on the test case. You pre-define properties by first clicking on the Properties tab in the test case window, then by clicking on the button to add a new property. You don’t have to provide a starting value. Go ahead and create a property called ‘new_property’.

Let’s go ahead and create a web service call. Click on the SOAP button or choose to add a test request step from the right click menu. A pop-up window will appear with all of the SOAP tests you imported earlier. Choose one. Another window will appear and let you name the step whatever you like. Give it a name and choose OK.

The next window should look very familiar. It’s the standard web service testing window. You can setup your web service test however you see fit. Make sure the test works and close the window. If your SoapUI is like mine you might want to save your project at this point in case SoapUI hangs or crashes.

Now let’s create a property transfer step. SoapUI may put it in the wrong location. The order of the test steps is important. When you run the test, SoapUI will execute them in order. You can simply drag and drop the test steps around to re-order them. Make sure the property transfer step is after the initial web service call.

You’ll have to stretch the window out to see all of the fields and options. Create a new transfer by clicking on the ‘+’ icon in the upper left of the window. Name it whatever you like. Now, next to the ‘Source’ field, choose the source of your property value. In our case, we’ll choose the previous web service step. For the source property, choose ‘Response’.

What we’ve done is chosen the XML returned after the web service call. In the box below the ‘Source’ field we can enter XPath to cherry pick out a value that will be used in later service calls. The only annoyance is that we need to declare any namespaces we use in the XPath query. For example:

declare namespace objmgr=""

The above query will pull out the response value for the objmgr:objectID tag.

In the ‘Target’ field, select the test case. In the target property field, select the ‘new_property’ field. Once this step is executed the test case ‘new_property’ variable will be set to the value of the web service response tag ‘objmgr:objectID’.

But how do we use that value? We can embed properties directly into the web service requests. For properties defined on the test case, you access them using this syntax: “${#TestCase#new_property}”.

Now when the test is run, a web service will be called and a value from the response will be used in a subsequent web service call.

If you want to do more complex processing between web service calls you’ll need to create a Groovy step. Groovy is a scripting language that looks very much like Java. Here, for example, is a Groovy step that replicates the above property transfer.

groovyUtils = new context )
holder = groovyUtils.getXmlHolder("Test Request#Response" )
objectID = holder.getNodeValue( "//objmgr:objectID" )
testRunner.testCase.setPropertyValue('new_property', objectID)

This code uses the SoapUI GroovyUtils object. It provides a helpful (and poorly named) function called ‘getXmlHolder’. You pass it a string with the name of the test step, e.g., ‘Test Request’, followed by a pound sign, followed by the test step property, e.g., “Request” or “Response”.

The resulting holder object lets you use XPath to query the XML. In the above example we then set ‘new_property’ to the value retrieved from the web service response.

The final piece in the puzzle is actually making sure that each test step works. This is done by adding assertions to each test request step.

Open a test request step. Click the button to add a new assertion. You can test if the schema is valid, if an XPath query resolves to a specific value, you can run a Groovy script or a number of other choices.

If you choose to run a Groovy script you signal a test failure by simply throwing an exception, e.g., ‘throw new Exception(“A failure occured”)’.

And that’s it. The SoapUI interface may not be particularly easy to navigate, but once you know where everything is and understand the concepts the tests are easy to write.