SoapUI Open Source is a functional API testing tool split across Maven submodules

The split between the open source edition and the commercial product

SoapUI is described as the world's leading testing tool for API testing, and the repository holds the open source edition of it. The distinction matters more here than in most projects, because the README is explicit about where the line falls.

The Advanced Functionality section says that SoapUI Open Source offers basic functionality for API testing, and that for additional features such as data-driven testing, coverage testing, Groovy script debugging and others, the recommendation is SoapUI Pro, the commercial product from SmartBear.

So the open source project is a complete, usable functional testing tool, and the commercial product adds a set of capabilities on top of it. That is an unusually clean open source and commercial split for a desktop application, and it is worth understanding before you evaluate either. A team that needs data-driven testing, meaning running the same test against a large dataset, is out of the open source edition from the start.

The licensing is also non-standard. The repository records a custom licence that GitHub cannot classify, with LICENSE.md and LICENSE.txt at the root, and the README states that by downloading the software you agree to the licence and privacy policy on the SoapUI website. So the terms are not the MIT or Apache text an engineer would expect from a project of this size, and the site is the authoritative source.

Five submodules, and one of them is for running the tests in CI

The Structure and submodules section is the clearest statement of the project's shape, and it is short.

The soapui module is the core module that creates the soapui.jar file. The soapui-system-test module holds integration and system tests for SoapUI, which is the module that tests the tool itself. The soapui-installer module creates SoapUI distributions, such as installers and archives. The soapui-maven-plugin is a Maven plugin used to run SoapUI in a continuous integration environment such as Jenkins, and the soapui-maven-plugin-tester is a test pom.xml file used to test the soapui-maven-plugin.

That last pair is the one that determines how a team would actually use this. A functional test suite for an API is a set of assertions that someone runs on every build, and a desktop GUI is not where that happens. The Maven plugin is what turns a project file into a CI step, and the tester module is the harness that keeps the plugin itself honest.

It also explains the top-level directory listing, which holds the pom.xml as the parent, the docker/ directory, a RELEASENOTES.txt, a SECURITY.md, an intellij-codestyle.jar and a SoapUI-oss-logo.png. The default branch is next, which is a development branch rather than a release branch.

The documentation points to a JavaDoc build with mvn javadoc:javadoc, and the generated output lands in the target/site/javadoc folder.

Building is Maven, and the requirements are recent

The prerequisites are OpenJDK 17, Maven 3.6.3 or later, and Git 1.8 or later. That is a modern baseline for a project of this age, and it matters for anyone on an older JDK.

Getting the source is a single clone:

git clone https://github.com/SmartBear/soapui.git

The build is a mvn clean install in the root folder, and to build an individual submodule you run the same command in the root folder of the submodule you want to build. Running it after a build is mvn exec:java in the root folder of the soapui submodule, and pulling the latest changes is a git pull in the root directory of the project or of the submodule.

That is a conventional Maven multi-module layout, and the practical effect is that a full build compiles everything including the system tests, which is slow. A developer iterating on the core module would want the submodule build rather than the root one, and the README says so.

The IDE support section gives the same instructions twice, once for IntelliJ IDEA and once for Eclipse, and both are worth reading because the entry point is not where a Java developer would expect it. The main class is com.eviware.soapui.SoapUI, and in Eclipse you run it with Run as and then Java application. In IDEA you right-click the class and select Run. For IDEA there is a tip about the code style settings: to get the code style used by the team, select File and then Import Settings and import the intellij-codestyle.jar file located in the root folder of the SoapUI project.

That jar being committed is a small signal about how the project is run, and the fact that the instructions are spelled out per IDE suggests that getting the run configuration right is a known friction point.

A Groovy scripting story, and the resources that support it

The Additional resources section is where the project's real usage guidance lives, and the second entry sets the tone.

There is the SoapUI community forum on SmartBear's site for discussing and participating in all things SoapUI. There is a separate repository, SoapUI Groovy examples, which is a collection of SoapUI projects and Groovy scripts used to demonstrate the Groovy scripting capabilities in SoapUI. And there are three developer corner pages, extending SoapUI, custom factories, and integrating with SoapUI, plus a Packt book, Mastering SoapUI, on testing and automating a SOA.

The Groovy angle is the part that tells you about the tool's design centre. SoapUI's scripting layer is Groovy, and the examples repository exists to teach it. The development corner pages point at a plugin architecture: custom factories, which is how you supply your own components, and integration, which is how you embed SoapUI in another system.

That combination, a GUI for authoring test suites, Groovy for the logic that is not expressible as assertions, and a plugin API for custom components, is the shape of a tool aimed at people who are not primarily programmers but who need to automate an API and need to reach beyond the built-in steps.

The three developer corner pages are the parts to read before extending the tool, because the extension model determines how much of your own code you can keep in your own project rather than in a fork.

Where SoapUI Open Source is the wrong tool

The first wrong-tool case is a need for the advanced features. The README names data-driven testing, coverage testing and Groovy script debugging as things to look for in the commercial product. A team that needs to run a test suite against a captured production dataset, or to measure which assertions actually fired, is looking at a paid edition from the start, and the open source repository will not close that gap.

The second is a test stack that is code-first. SoapUI's model is a project file, edited in a desktop application and versioned alongside the code. A team whose API tests are pytest functions, or whose HTTP calls are made from a TypeScript test suite, is building the same assertions twice, and the duplication is worse than it looks because the two suites drift.

The third is what a twenty-year-old desktop application costs. SoapUI's own version numbering, its Swing interface, the EVIWARE package names inherited from the original company, and the Maven plugin that has to keep working with whatever CI you already have, all add up to a stack where the integration work is a real part of the effort rather than an afterthought. That is not a criticism of the design, it is what a mature desktop tool costs when you embed it in a modern pipeline.

The fourth is the Docker story. The repository has a docker/ directory, which means containerised use is supported, but the README does not describe running the tool in a container, so a team planning to run the Maven plugin inside a container image is working from the directory contents rather than from documentation.

Editorial conclusion

SoapUI Open Source fits a team that wants a desktop application for authoring and running API functional test suites, especially one that already has CI infrastructure where the Maven plugin can run those suites, and it does not fit a team that needs data-driven testing, coverage testing or Groovy script debugging. Before adopting it, read the Advanced Functionality section in the README and confirm the features you need are in the open source edition, and note that the licence is a custom one with terms on the SoapUI website rather than a standard open source licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SmartBear/soapui on GitHub