SOA Suite 11g Dynamic Payload Testing with soapUI Free Edition
- by Greg Mally
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:
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 :)
