My SoapUI Thoughts on Effective Testing in SoapUI

Scriptless Loops

A common technique in data-driven testing involves iterating over a sample of records in a database and confirming that the API returns correct data for each record.



  • A test case which uses the Conditional Goto test step to iterate over the call to GET Post, using a different post id value retrieved from the database for each iteration.

The Conditional Goto test step

Ah, the Conditional Goto test step. This humble type of test step has been the subject of much misinformation online, including claims that it can’t be used to control a test case loop or that it only works with XPath expressions. This article will show that when you’re working with a database it’s perfectly easy to set up an iterating test case with almost no scripting. In fact, here are some of the things you don’t need in order to iterate over the test steps in a test case:

  • groovy script test steps
  • properties steps
  • property transfer steps
  • money for a SoapUI licence

Now that we’ve got these misconceptions out of the way, let’s see how easy the task actually is.

The Setup

Firstly, the test case needs to know how many times you want it to run the test steps. Do this by adding a test case property called iterations and set its value to 5.

Secondly, the test case needs to keep track of the number of iterations it has already completed. For this, we should look at the context map.

Whenever you create a Groovy script test step, you’ll see at the top of the script window a list of two or three variables that the script can access. In all scripts related to test cases, the context variable appears in this list. The context is a map of values that is accessible from anywhere within a test case. The handy thing with the context map is that you can add your own members to it, like this:

context.rowCount = 0

This statement adds a rowCount member to the context map and initialises its value to 0. You should place this statement into the Setup Script in the test case so that the test case window looks like this. TCSetupScript01 This ensures that the iteration always starts from 0 each time the test case is run.

Configuring the Goto step

The next task is to create a Conditional Goto step to control the behaviour of the iteration. To do this, add a step of this type called Get Next Record to the end of the test case and configure it to look like this, with a Condition named iterator. GetNextRecord01 In this example, the iterator Condition has been configured with the following expression:

${=++context.rowCount} < ${#TestCase#iterations}

This syntax may be unfamiliar, so let’s look at it in detail. (Note that there’s no use of XPath here, despite the name of the field in the dialog.) The left side of the comparison is an example of a dynamic property in SoapUI, in which everything to the right of the ‘=’ sign is considered to be a script in its own right. Here the value of the rowCount variable is being incremented by 1 before being compared to the value of the iterations property on the test case. If the comparison evaluates to true, then the Get Next Record step will pass control to the test step selected in the Target Step dropdown. In this case, if the rowCount is less than the required number of iterations, we want the test case to return to the JDBC step so that the SQL query returns a new record for the REST step - or steps - to retrieve.

If the condition evaluates to false then the test case resumes with the test step following the Conditional goto. Here there is no following test step, so the test case ends.

That’s it! You should now be able to run the test case and observe the test steps executing 5 times. Each time they run, they will reference a randomly selected POST record from the database. If you change the iterator value to 2 and re-run the test case, the test case window should look like this. SingleRecordTC01 This should be enough to show that it’s possible to build data-driven, iterative test cases in SoapUI without the need for groovy test steps.

Using a script

Having shown that the Conditional Goto test step can allow you to build an iterative test case without a Groovy script, for the sake of completeness I’ll show that the same effect can be achieved with scripting very easily. As an alterntive to the Get Next Record test step, you could insetead create a Groovy test step with the following contents.

if( ++context.rowCount < context.expand( '${#TestCase#iterations}' )?.toInteger() ) {
	testRunner.gotoStepByName( 'SQL GetPosts' )

This script is so close conceptually to the Conditional Goto step that it’s almost a matter of personal preference which approach you take. I favour the Conditional Goto test step because if you change the name of the target test step from ‘SQL GetPosts’ to something else, the Conditional Goto step will update the name automatically. If you’ve used a script you’d need to remember to update the call to gotoStepByName manually.

Let’s turn our attention to how to handle REST calls that return multiple records.