Overview

Many web service developers use soapUI for various tests like: smoke test, unit test, and load testing because you can get a free edition that is fairly robust. However, if you need to venture into more complex testing that requires a dynamic payload, then the free edition doesn't necessarily make it easy. This feature does exist in soapUI, but for obvious reasons it is in the Pro version. In this blog I will show you how to use soapUI free edition for dynamic payloads in a simplified example. Hopefully this will open the doors for you to expand into more complex scenarios.

The following assumes that you have a working knowledge of soapUI and will not go into concepts like setting up a project etc. For the basics, please review the documentation for soapUI: http://www.soapui.org/Getting-Started/. Additionally, we will be using asynchronous web services and you can review the setup for this in my blog: SOA Suite 11g Asynchronous Testing with soapUI.

Features in soapUI Free Edition Relating to this Topic

The soapUI test tool provides a very feature rich environment that can do many things provided you are willing to go beyond point and click. For this example, we will be leveraging just a couple features for our dynamic payload example:

• Test Case Properties

• Scripting with Groovy

Basically, we will be using a property as a global variable and we will manipulate that property using a Groovy script.

Setting Up Our Property

Properties are available throughout soapUI and here is a snippet from the soapUI website defining the locations:

• Projects : for handling Project scope values, for example a subscription ID

• TestSuite : for handling TestSuite scoped values, can be seen as "arguments" to a TestSuite

• TestCases : for handling TestCase scoped values, can be seen as "arguments" to a TestCase

• Properties TestStep : for providing local values/state within a TestCase

• Local TestStep properties : several TestStep types maintain their own list of properties specific to their functionality : DataSource, DataSink, Run TestCase

• MockServices : for handling MockService scoped values/arguments

• MockResponses : for handling MockResponse scoped values

• Global Properties : for handling Global properties, optionally from an external source

For our example, we will be defining a custom property in a TestCase called SimpleAsyncPayload. The property can be created in either the Custom Properties tab located at the bottom of the Navigator panel when the TestCase is selected in the Navigator or the Properties label in the TestCase editor:

Navigator Panel

TestCase Editor

You will notice that I set a value of “0” for the custom property. For this simplified example, we will need to retrieve that value and manipulate it prior to making the web service request invocation. In order to accomplish this, we will need to get Groovy ;)

Let's Get Groovy

We will now add a new Groovy Script step to the TestCase called Manipulate Payload:

TestCase Editor > Append Step > Groovy Script

Once we have added the Groovy Script step to our TestCase, we can open the Groovy Script editor to add the code to:

1. Get the current value of the property we created called SimpleAsyncPayload.

2. Convert the value of the property to an integer.

3. Increment the value.

4. Store the incremented value back into the TestCase property called SimpleAsyncPayload.

The script should look something like the following:

Groovy Script Editor – Manipulate Payload

At this point we can test the script to see if it is working by simply running the TestCase (left-click on the green triangle in the upper left-hand corner of the TestCase editor). To verify if it ran correctly, we can look at the value of the SimpleAsyncPayload property which should now be 1:

TestCase Editor – Run Results

All that is left to complete the TestCase is to append another step of type Test Request. The information required to append the request is a name and an operation to invoke. In this example we will use the default name and select the SimpleAsyncBPELProcessBingd -> process as the operation (any other information being requested, simply use the defaults unless you are calling an asynchronous operation then do not add any assertions). We are now in familiar ground with the Test Request editor. Depending upon the type of operation you are invoking (synchronous or asynchronous), please update the request with the necessary information (e.g., callback information for asynchronous operations).

We will now tweak the Test Request payload to retrieve the value of the SimpleAsyncPayload property. The soapUI editor makes this very simple: right-click in the payload and navigate to the property (e.g., right-click > Get Data.. > TestCase: [Groovy TestCase] > Property [SimpleAsyncPayload]):

Test Request Editor – Insert Property Value

Your payload should now look something like the following:

Test Request Editor – Inserted Property Value

Just like before, we are now ready to run the TestCase. If everything goes as expected we should see a response like the following:

Message Viewer – Results of TestCase Run

We are now setup to be able to run a stress test where the payload will change for each request. This simple example can be expanded to include multiple payload values, complex calculations in the scripts, or whatever can be done via the soapUI scripting. Hopefully you have found this useful and happy testing to you :)