SOA Suite 11g Dynamic Payload Testing with soapUI Free Edition
By Greg Mally on Aug 30, 2012
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:
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:
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:
Get the current value of the property we created called SimpleAsyncPayload.
Convert the value of the property to an integer.
Increment the value.
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 :)