1. Property Expansion in soapUI
SoapUI provides a common syntax to dynamically insert ("expand") property values during processing. The syntax is as follows:
${[scope]propertyName[#xpath-expression]}
where scope can be one of the following literal values:
- #Project# - references a Project property(Reference properties across a particular SoapUI project)
- #TestSuite# - references a TestSuite property in the containing TestSuite
- #TestCase# - references a TestCase property in the containing TestCase
- #MockService# - references a MockService property in the containing MockService
- #Global# - references a global property. Found in File>Preferences>Global Properties tab. Reference properties across all projects
- #System# - references a system property. Found in Help>System properties.
- #Env# - references an environment variable
- [TestStep name]# - references a TestStep property
Many of the scopes will of course only work if they are available, i.e. you can not use the #MockService# scope within a TestCase script since there is no containing MockService to access.
If no scope is specified, the property is resolved as follows:
- Check the current context (for example the TestRunContext) for a property with the matching name
- Check for a matching global property
- Check for a matching system property
If the property expansion further includes an XPath expression, this will be used to select the corresponding value from the referenced property value (which must contain XML), for example the following example could "extract" the author value from a preceding response with:
${Search Request#Response#//ns1:Item[1]/n1:Author[1]/text()}
Which would first get the "Response" property of the "Search Request" step and then select the value of the first Items' first Author element. Note that the namespace prefix must match those used in the response message, otherwise the expansion will fail.
As you can see, there is no way to access properties "outside" scope, i.e. you can not access a property in another TestCase from within a TestStep. This is a deliberate restriction aiming to reduce dependencies between items. If you need to transfer values between (for example) two TestCases you should use the containing common TestSuite or Project as an intermediary; the first TestCase transfers to the common parent using a Property-Transfer or Groovy script, the second reads from the same parent. In this way, there is no direct dependency between the two TestCases and the value supplied by the first TestCase can be supplied by any other source (TestCase, Script, etc...) or statically.
Property Transfers are a more tedious way of accomplishing the same functionality as with property-expansion. On the other hand, property transfers provide the possibility to transfer complex content between request, response messages. Also, the result of a Property Transfer is visible directly in the corresponding request, response editors.
Property-Expansion is supported wherever a value is to be specified, if you find a place where it doesn't seem to work like you want please let us know!
2. Dynamic Properties
SoapUI 2.5 introduced the possibility to write groovy scripts directly inside a PropertyExpansion; prefix the content with a '=' and the remaining content up to the closing brace will be evaluated as a script and its result will be inserted. For example
${=(int)(Math.random()*1000)}
will be replaced with a random number between 0 and 999 every time it is evaluated.
Of course this applies to all places where property-expansions can be used; requests, property values, file names, endpoints, etc.. etc..
Depending on the context of the expansion, relevant variables will be available for accessing the soapUI object model. For example in a request message or parameter, the containing Request object will be available through the "request" variable, allowing you to (for example) insert its name in your request
...
${=request.name}
...
or if you want the name of the project just navigate up the soapUI ModelItem tree:
...
${=request.operation.interface.project.name}
...
If you want to provide a current formatted timestamp:
...
${=import java.text.SimpleDateFormat ; new SimpleDateFormat("YYYY-MM-DDT00:00:00").format(new Date())}
...
The following variables are (almost) always available in these scripts:
- log : a log4j Logger logging to the groovy log window
- modelItem : the current modelItem (for example a Request, MockResponse, etc..).
- context : the current run-context (for example when running a TestCase or MockService)
For ReadyAPI users, the global script library is available just as in any other script, allowing you to call into objects/methods defined there for reuse. One current limitation is that although scripts can be multiple lines, they can not contain nested braces (yet).. as always there is room for improvement!
3. Nested Properties
SoapUI supports both nested and recursive property-expansion (be careful!), for example:
test = "value"
testexp = "${test}"
-> "${testexp}" evaluates to "value"
testexp = "value"
exp = "${exp}"
-> "${test${exp}}" evaluates to "value"
testxml = "hello"
testxpath = "//value[@id=${id}]/text()"
id = "123"
-> "${#testxml#${testxpath}}" evaluates to "hello"