Getting started with SoapUI

  September 30, 2013

When I stepped into the role of Sales Engineer for SoapUI Pro almost a year ago, I fully immersed myself into the product and the community that was built around it.  Prior to SmartBear, I used the open source version of SoapUI to call a SOAP web service and validate its response.  That single unit test barely scratched the surface of all of the functionality available in SoapUI.  So here are some tips I found useful for people who are testing their services and APIs with SoapUI for the first time.

First off, I had to change the way I perceived the following:

  • Despite the “Soap” part of SoapUI name, SoapUI is not just a SOAP web service testing tool.  A lot of people depend on SoapUI for REST, JMS, JDBC and AMF testing.  They incorporate SoapUI into their continuous integration builds, IDEs (IntelliJ, NetBeans, and Eclipse), API monitoring, etc.  There’s absolutely no shortage of creative uses for SoapUI out there. For one outstanding example, see a test framework implemented around SoapUI that follows Gherkin’s traditional “Given/When/Then” steps.
  •  I’ve also modified my definition of “API” to include any specification defining computer-to-computer interaction.  This new definition includes SOAP and REST web services, JDBC, JMS, etc.  Previously “API” to me would mean software libraries such as one for SoapUI:

When you’re diving into SoapUI, it’s important to understand how everything is organized.  So below I have a screenshot and explanations of each component in a SoapUI project:


  1. Workspace – top level placeholder for your projects.  Usually there’s one created when you first start SoapUI
  2. Projects – includes all of your tests and API references (Interfaces).  Behind the scenes a project is saved as a single XML file, but you can split it up to add your tests to source control and share with the team
  3. Interface – this is the mapping from SoapUI to your web service.  It lets users see the descriptors, included methods, operations, etc.  So if your web service changes, you would have to change the Interface component.  Also if you want to, for example, make a call to one web service and pass the response into another web service; both web service Interfaces would have to be defined within the project
  4. Test Suite – a placeholder for Test Cases.  Once you start writing test case scenarios and start gathering dozens or hundreds of tests, Test Suites will help you organize them
  5. Test Case – a collection of Test Steps that are assembled to test some specific aspect of your service(s)
  6. Test Steps - the core building blocks of functional tests in SoapUI where each Test Step performs some step for validating the functionality to be tested

Now that you know how these objects are organized, you can easily create objects and perform different actions with another important tip:

  • Right-click your way around SoapUI

There’s a lot to discover in SoapUI, and a lot of features and functionality are contained in the right-click menus.  In fact you can create, edit and maintain your test cases through right-click actions.

So at this point of ramping up with SoapUI, we are still missing a major component in our API tests: validation.  While we can structure our tests, we don’t want to look through each test run result to confirm that APIs work as expected.  So to automate the validation piece, SoapUI uses assertions.  If you go into your SOAP or REST test step, you can see the assertions tab at the bottom that will allow you to configure your validation rules:


So while we have 22 available types of assertions, the ones I usually see applied are:

  • Contains – searches for the existence of a substring in the response
  • Message Content Assertion – allows you to verify multiple XML node values in a single assertion
  • XPath Match – uses an XPath expression to select content and compares that to an expected value
  • Not SOAP Fault – validates that the last response received from a SOAP web service was not an error
  • Schema Compliance – validates that the last received message is compliant with the associated WSDL or WADL schema definition
  • Response SLA – validates that the last response was received within a specified time limit
  • Script Assertion – runs a custom script to perform user-defined validations

For more information on assertions, see this link.

So with this basic knowledge of SoapUI you can perform some very comprehensive API tests.  Once you get comfortable creating functional tests, you can then use them for load testing, monitoring, identifying security flaws, and much more.  Stay tuned for future articles describing this functionality.

See also:

[dfads params='groups=933&limit=1&orderby=random']

[dfads params='groups=937&limit=1&orderby=random']