How To… SoapUI: Using Dynamic Properties

Reading Time: 4 minutes

Every month on the third Tuesday as part of our How To…Series, we feature a new post with a guide on how to solve a particular problem with SOAP UI with guest blogger Brendan Connolly. This month Brendan looks at Dynamic Properties.

Find More of the How to..Soap UI series here:

How To…Basic Request And Response Logging Using Testrunner

How To…REST Without WADL

How To…Testing Client Timeouts And Delays

How To…Complete Parsing With Groovy

 

Why Dynamic Properties

Static test content can cause problems. An easy example of this are dates and times. Credit card expiration dates, order dates, tests with fixed date/times may run fine for months even years and suddenly start having problems as those hard coded dates take on a different context and change the tests desired behaviour.

request_suite_property

 

Ok, so SoapUI lets you inject data directly into the request.

request_inline_code dynamic properties

 

In the first example can you tell the significance of that date? In the second example can you easily tell what the inline groovy snippet’s code means? If you want to change the format how many places would you need to update?

Here’s how to use dynamic properties to address those concerns and end up with a set of portable, flexible and reusable properties you can use in any test.

How to Create A Dynamic Property

The property window is not the easiest place to write code, even if it is just short snippets. I use an online Groovy editor like Groovy Web Console  or JDoodle to get the code for the property ready first.

Then its just a matter of adding a custom property in SoapUI, which can be done at the Project, TestSuite, or TestCase level. In this case we will add one to to our test suite.

Select your TestSuite from the Navigation tree

selecttestsuite dynamic properties

 

Click Custom Properties, then use the + icon to add a property

customproperty_add dynamic properties

 

Then enter the name and your code snippet in the fields provided.
In order for the code to be interpreted the value field must be in the format ${= your code here}.

propertyentry

 

If there are multiple statements they will need to be separated by a semi-colon (;)
For example:

${=import static java.util.UUID.randomUUID; randomUUID() as String }

How to Use A Dynamic Property

What sets dynamic properties apart is that they help the test to be more readable and more easily maintained. It also doesn’t require an additional Groovy Script test step.

You can use a dynamic property like any other property. Since we added our example to the TestSuite, inside a request call the property using the following format ${#TestSuite#YourPropertyName}

request_suite_property dynamic properties

 

How to Reuse

Now you have some properties created for your test suite, what happens when a new project comes along? Do you have to copy and paste them by hand into the next test suite?

SoapUI allows properties to be exported and the result is a very simple text file where the format is PropertyName=Value.

To Export, navigate to the custom properties tab of the TestSuite and click the last icon on the right. Then choose your file name and location and click save.

export_properties

DateTime_Now=${=new Date().format(“yyyy-MM-dd’T’HH:mm:ss.SSSXXX”)}
DateTime_YearFromNow=${=new Date().plus(365).format(“yyyy-MM-dd’T’HH:mm:ss.SSSXXX”)}
GetNewOrderUUID=${=import static java.util.UUID.randomUUID; randomUUID() as String }

You can also turn around and import values using the same format. This means you could write up your own dynamic properties outside of SoapUI and then import them in.

To import navigate to the custom properties tab of the TestSuite and click the second to last icon on the right. Then browse to your properties file.

import_dynamic properties

 

Once your file is selected you will be presented with a few options for how to load your properties.

dynamic properties

Then just click ok and your properties will be ready for use.

About the Author

Brendan

I am a Software Design Engineer in Test based out of Santa Barbara, California. Working in a variety of testing roles since 2009. I am responsible for creating and executing testing strategies and using his coding powers for developing tooling to help make testers lives easier. He writes tests at all levels from unit and integration tests to API and UI tests. I blog on testing and automation at Brendanconnolly.net or follow me on Twitter @theBConnolly
Find out more about @brendanconnolly

Leave a Reply