soapUI: Properties

I wanted to jump into a survey of the various test steps in this post, but quickly realized that an explanation of properties was necessary first.  Properties are a key concept in soapUI that can make test suites more flexible and modular.  You can define and reference your own custom properties (which you can think of as being akin to variables in soapUI) or use "built-in" properties to reference bits of information between test steps and test cases-- for example, referencing part of one request test step's response XML to use as an input parameter in another request test step.

Properties are available at multiple levels in soapUI, including the environment, system, global, project, test suite, test case, and test step levels.  System properties are visible in the Help - System Properties window.  Global properties can be viewed or set in the File - Preferences window.  Properties for other levels are visible in the Navigator panel when you click on the relevant node.


Project properties panel
In some cases, properties can also be loaded from or saved to external files (see the screenshot below of a test suite Custom Properties tab; the two rightmost icons at the top of the dialog are for loading and saving from external files).  Properties are saved in the file in propertyname=propertyvalue pairs; e.g.:

ElName=Mercury
ExpectedVal=80

Properties can be referenced (soapUI documentation calls this property expansion) from almost anywhere in soapUI-- in Contains assertions as the string to match, within a request, etc.  To reference a property, the general syntax is "${[#PropertyScope#]PropertyName[#XPathExpression]}".  PropertyScope can be "Env", "System", "Global", "Project", "TestSuite", and "TestCase" (in the screenshot above, the Hermes Config property references the user.home System property).  To reference properties from a preceding test step, the syntax is "${TestStepName#PropertyName[#XPathExpression]}-- note that the leading hash mark (#) before the scope is omitted when referencing a test step.  The test step where you're putting your reference and the test step being referenced must be within the same test case.  XPath expressions are optional and only valid where the property being referenced is valid XML (for test requests, the request and response are both made available as properties).

Let's go back to the test suite created in the last post for our Periodic Table web service.  Note that three of the four operations provided by the web service take an element name as their input parameter: GetAtomicNumber, GetAtomicWeight, GetElementSymbol.  Suppose we wanted to use the same element to test all three.  Instead of hard-coding an element into our requests, we can define a test suite level property and then use that property in all three of our test requests.

Let's try that now.  In the Navigator panel, click on the test suite node.  In the Properties panel (click the Properties button at the bottom of the Navigator panel if you don't see it), click on the "Custom Properties" tab, and add a new property called ElNameProp (via the left-most button at the top), giving it "Silver" as its value.


ElNameProp created at the test suite level
Now go into the GetAtomicNumber, GetAtomicWeight, and GetElementSymbol test requests and modify each to use our test suite's ElNameProp where an element name is required. Our reference expression is "${#TestSuite#ElNameProp}". Here's the reference in the GetAtomicNumber test request:


ElNameProp used in the GetAtomicNumber test request
Now try running each of the modified test requests-- the value "Silver" is plugged into each of the requests where we reference our ElNameProp property (you can see some of the appropriate response data for the GetAtomicNumber request in the screenshot above).