SoapUI REST Testing, Property Transfer and Data-Driven Tests

SoapUI isn’t only for SOAP. Many enterprise QA teams use one SoapUI project for both their legacy SOAP services and their newer REST APIs. In this lesson you’ll build a REST project against the live SQA Tools practice API, assert JSON with JSONPath, pass a login token between steps with Property Transfer, write small Groovy scripts and run a data-driven test from a CSV file, all with the free open-source edition.

Create a REST Project

1. File → New REST Project.
2. URI: https://sqatools.in/wp-json/sqa-api/v1/users/1 and click OK.
3. SoapUI splits it into a service (endpoint https://sqatools.in), a resource (/wp-json/sqa-api/v1/users/1), a method (GET) and a request.
4. Click the green arrow. Switch the response view to JSON; check Raw for status and headers.

Alternatively, Import an OpenAPI/Swagger file (File → Import Swagger/OpenAPI, or via the plugin in some versions) to create every resource at once.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

Better structure with parameters

Edit the resource path to /wp-json/sqa-api/v1/users/{id}. SoapUI adds a TEMPLATE parameter id. Add QUERY parameters such as role, page, per_page on a /users resource. Parameter styles: QUERY, TEMPLATE (path), HEADER, MATRIX, PLAIN.

Create a TestSuite for the REST API

Right-click a request → Add to TestCase, as you did for SOAP.

JSON Assertions in SoapUI

For older SoapUI versions without JsonPath assertions, SoapUI also exposes JSON responses as XML, so XPath Match works on them too (e.g. //data/name).

Script Assertion (Groovy) for business rules

import groovy.json.JsonSlurper

def json = new JsonSlurper().parseText(messageExchange.responseContent)
def order = json.data

order.items.each { item ->
    assert item.line_total == item.quantity * item.unit_price
}
def subtotal = order.items.sum { it.line_total }
assert order.summary.subtotal == subtotal
assert Math.abs(order.summary.total - (subtotal * 1.18)) < 0.01
assert messageExchange.timeTaken < 2000

Attach it to a GET /orders/5001 step: it proves the totals are internally consistent, which no simple Contains check can.

Property Transfer: Chain Login → Protected Call

1. Step 1, REST Request “Login”: POST /wp-json/sqa-api/v1/auth/login, media type application/json, body:

   { "username": "${#Project#username}", "password": "${#Project#password}" }

2. Add TestCase property token (empty).
3. Step 2, Property Transfer: Source = Login, Property = Response, path language JSONPath, path $.access_token. Target = TestCase, Property = token.
4. Step 3, REST Request “Me”: GET /wp-json/sqa-api/v1/auth/me, add header Authorization = Bearer ${#TestCase#token}.
5. Assert on Step 3: status 200, JsonPath $.data.role = admin.

Set project properties username = admin and password = admin@123 (these are public practice credentials). For real systems, pass passwords at run time with -P on the command line instead of saving them in the project file.

Property expansion syntax

Groovy Script Steps: Small Code, Big Wins

A Groovy Script test step can generate data, read files, call other steps and log. Some everyday snippets:

// Unique test data
def uid = UUID.randomUUID().toString().take(8)
testRunner.testCase.setPropertyValue("objectName", "soapui-" + uid)

// Read a property and log it
def token = testRunner.testCase.getPropertyValue("token")
log.info "Token starts with: " + token?.take(12)

// Read the previous step's JSON response
def resp = context.expand('${Create Object#Response}')
def id = new groovy.json.JsonSlurper().parseText(resp).id
testRunner.testCase.setPropertyValue("objectId", id)

// Run another step by name
testRunner.runTestStepByName("Delete Object")

Data-Driven Testing from a CSV (Open Source)

Goal: test the age boundaries of POST /validate/user (18 to 100) from a file.

age,expected
17,422
18,200
100,200
101,422

TestCase “Validation – data driven” with three steps:

1. Validate (REST Request, disabled so it runs only when called): POST /wp-json/sqa-api/v1/validate/user with body

   { "name": "Asha", "email": "asha@example.com", "age": ${#TestCase#age} }

2. Loop (Groovy Script):

   def rows = new File(context.expand('${#Project#dataDir}') + "/ages.csv").readLines().drop(1)
   def failures = []
   rows.each { line ->
       def (age, expected) = line.split(",")*.trim()
       testRunner.testCase.setPropertyValue("age", age)
       def result = testRunner.runTestStepByName("Validate")
       def status = result.messageExchange.responseStatusCode
       log.info "age=${age} -> ${status} (expected ${expected})"
       if (status != (expected as int)) failures << "age ${age}: got ${status}, expected ${expected}"
   }
   assert failures.isEmpty() : failures.join("\n")

The script fails the TestCase with a clear list of mismatches. Add more columns (name length, email format) to cover other fields.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Asha","email":"asha@example.com","age":101}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

Environments and Endpoints

• Use a project property for the host (${#Project#host}) in the service endpoint.
• Override at run time: testrunner.sh -Phost=https://qa.example.com ....
• ReadyAPI adds an Environments switcher similar to Postman’s.

Common SoapUI Problems and Fixes

Running REST Suites in CI

./testrunner.sh \
  -s"SQA Practice REST" \
  -PbaseHost=https://sqatools.in \
  -Ppassword="$QA_PASSWORD" \
  -r -j -f ./reports \
  SQA-Practice-soapui-project.xml

Publish reports/*.xml with your CI’s JUnit report step. A failing assertion returns a non-zero exit code and fails the build.

SoapUI vs Postman vs Playwright for REST

Interview Questions: SoapUI REST and Data-Driven Testing