SoapUI review: what it is, tutorial, pros and cons

A SoapUI project starts from a WSDL or an OpenAPI definition, or from requests added by hand. From a WSDL, SoapUI creates an interface with every operation and a sample request whose XML follows the schema, which is the main reason it is still used for SOAP: building correct envelopes for large enterprise schemas by hand is slow and error-prone. Under the interfaces sit test suites, test cases and test steps, such as requests, property transfers, Groovy scripts and delays, each with its own assertions. The whole project, including tests and mocks, is saved as one XML file.

Each request step carries assertions: Contains and Not Contains, XPath Match and XQuery Match, Schema Compliance against the WSDL, SOAP Fault and Not SOAP Fault, valid HTTP status codes, WS-Security Status, Response SLA and Script Assertion written in Groovy. Values move between steps with property transfers or through property expansion, a syntax such as ${#Project#baseUrl} or ${#TestCase#orderId} that is resolved when the step runs. Properties live at global, project, test suite, test case and step level. This makes multi-step flows possible without code, at the cost of logic being spread across many dialogs rather than visible in one file.

When the built-in steps are not enough, Groovy Script steps and script assertions can do almost anything. Script steps receive testRunner, context and log, and can read or set properties anywhere in the project; script assertions receive messageExchange, context and log, but not testRunner, so they reach the project through messageExchange.modelItem. Groovy has access to SoapUI’s own Java classes, such as GroovyUtils and XmlHolder for XPath work. This power is also the risk: large suites accumulate scripts that only their author understands, stored inside the project XML.

The installation includes testrunner.sh and testrunner.bat, which run a project file from the command line. Options select the test suite and test case, override the endpoint, set project and global properties, print a summary, export JUnit-compatible reports and choose the results folder. Some options documented on the same page, including -E for environments and the PDF and custom report options, require ReadyAPI. SmartBear also publishes the smartbear/soapuios-testrunner Docker image, which mounts a project folder and runs the testrunner with arguments from an environment variable, so CI agents need no desktop installation.

Because a project is one XML file, structure matters more than in most tools. Keep one project per service or integration, not one per team, so the file stays small enough to review. Organise test suites by business capability and keep test cases independent, each creating or looking up its own data. Hold endpoints, credentials and environment-specific values in project properties, never inside requests, and override them with -P on the command line so the same file runs against every environment without ReadyAPI’s environment feature. Agree that one person merges changes to a project at a time, or split large projects, because concurrent edits to the same XML file conflict badly.

For REST responses, Contains and status assertions cover simple checks. When an assertion needs logic, such as totals matching line items or every element having a valid status, a short script assertion with Groovy’s JsonSlurper is clearer than chaining several dialogs. Keep scripts focused on one rule, name the assertion after that rule so the failure explains itself in reports, and read configuration with context.expand rather than hard-coding values. Put a failure message on each assert, because the message is what appears in the JUnit report when the suite runs in CI.

The official testrunner image keeps CI agents free of a desktop installation. Mount the folder holding the project, mount a folder for reports, and pass testrunner arguments through COMMAND_LINE, using %project% and %reports% to refer to the mounted volumes. Use -j for JUnit-compatible XML so the CI server shows results, -P to inject environment-specific properties from secrets, and -e to point requests at the right endpoint. The image’s documented examples use -it, which needs a terminal; on hosted runners, drop it so the container runs non-interactively.

Commit the project XML, but treat it as generated output that people edit through the tool: review changes by running the suite and reading the test names and assertions in SoapUI, not by reading the diff alone. Keep shared Groovy logic small and documented at the top of each script, and prefer built-in assertions where they suffice, since they are visible in the interface and in reports. Version 5.8.0 added AES-256 project encryption, which protects credentials in the file but also makes diffs unreadable, so use it only for projects that must hold secrets. Upgrade deliberately: read the release notes, which for recent versions are mostly library and security updates, and rerun the suite on the new version before switching CI.