Integrating soapUI into your unit testing practice

Using SoapUI testing tools is one of the easiest ways to ensure a high-level of application quality and security, thanks to this indepth expert tutorial. In this tip learn the cause and effect of user interface testing, documented in informative charts and code writing assistance.

In previous articles we took a basic look at creating functional test suites and performance test suites with soapUI, and we also built a mock web service to support our testing. While you can do a lot using the soapUI client application, I find that these tests are best run as part of your continuous integration environment. And the entire reason you would created a mock web services was so it will be available for use while testing. In this article we are going to look at how to leverage all of those assets while unit testing.

Introduction to the runners and their arguments

In addition to providing support for the Maven 1.X and 2.X plug-ins, soapUI conveniently provides a series of command line tools for running TestCases, LoadTests, and MockServices:

Tool Description Class
SoapUITestCaseRunner Runs specified TestCases and reports/exports results as configured com.eviware.soapui.tools.SoapUITestCaseRunner
SoapUILoadTestRunner Runs specified LoadTests and reports/exports results as configured com.eviware.soapui.tools.SoapUILoadTestRunner
SoapUIMockServiceRunner Runs specified MockServices com.eviware.soapui.tools.SoapUIMockServiceRunner

Each "runner" is defined in the class identified in the table above and takes the path to your soapUI project file as an argument. In addition, there are other common argument switches across the different runners: Common to all three runners: 




Sets project password for decryption if project is encrypted


Sets password for soapui-settings.xml file

The SoapUITestCaseRunner and SoapUILoadTestRunner have the following switches in common:




The endpoint to use when invoking test-requests, overrides the endpoint set in the project file


The host:port to use when invoking test-requests, overrides only the host part of the endpoint set in the project file


The TestSuite to run, used to narrow down the tests to run


The TestCase to run, used to narrow down the tests to run

The switches "e" and "h" allow you to quickly switch between test environments without having to update your tests. In addition, "s" and "c" allow you to narrow your test selection to specific cases and suites. Aside from the shared switches above, if you're using the SoapUITestCaseRunner you might also be interested in the following:




Do not stop if error occurs, ignore them


Turns on exporting of JUnit-compatible reports


Turns on exporting of all test results, not only errors

Similarly, if you're using the SoapUILoadTestRunner you might also be interested in the following:




The LoadTest to run, used to narrow down which LoadTests to run


Specifies the root folder to which test results should be exported

The most common SoapUIMockServiceRunner switches:




Turns off blocking when mockRunner has been started


The name of the MockService to run


The local port to listen on, overrides the port configured for the MockService


The local path to listen on, overrides the path configured for the MockService

Running your tests and mock services

There are two ways to run your tests, and both have advantages. The simplest way is to just run your tests directly from the command line using test runners provided by soapUI. This is handy because it lets you run your tests from any language and using any continuous integration tools you'd like. All you need to do is build some support scripts/tools to help you parse and sort the results that get generated so you can report on them in the same way you report on all your test results.

In the bin directory, you'll see two testrunner batch files: testrunner.bat for running functional tests and loadtestrunner.bat for running load. Each is executed using the project file and the switches defined above. For example if we were to run the JIRA tests from the other articles in this series we might have something like: testrunner.bat c:\projects\jira.atlassian-soapui-project.xml
loadtestrunner.bat -ehttp://localhost:8088/mockjirasoapservice-v2SoapBinding c:\projects\jira.atlassian-soapui-project.xml

Those commands would run all the tests or load tests defined in the jira.atlassian-soapui-project.xml file.

The other way to call the testRunner is from your JUnit tests. In their example documentation online, soapUI provides the following code as an example of what that looks like:

public void testRunner() throws Exception
SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
runner.setProjectFile( "src/dist/jira.atlassian-soapui-project.xml" );

Listing 1: Invoke the testrunner from with JUnit.

If you already use JUnit (or TestNG), this approach is likely the most desirable since it's in the format you're already using. You may also be interested in the Maven plug-in (described in more detail below).

Similar the test runners above, soapUI contains a mockservicerunner.bat script for running MockServices. For example, if we wanted to start the JIRA mock service we created in the previous article, we'd run something similar to the following:

mockservicerunner.bat -m"jirasoapservice-v2SoapBinding MockService" "c:\projects\jira.atlassian-soapui-project.xml"

Once startup is complete, we can now invoke this services using any client we like. This allows us to run either soapUI tests that rely on this mock service, or we can run any other tests we might have that require this mock service. This is fantastic for unit tests outside of soapUI which require mock functionality.

Using the soapUI Maven plug-in

If you're not familiar with it, Maven is a Java-based build management tool put out by Apache. The goal of Maven is to make day-to-day code management easier by allowing developers to comprehend the complete state of a development effort in the shortest period of time. It does this by simplifying the build process (managing dependencies, providing uniformity and visibility, etc…) and it's commonly used in conjunction with other build management / continuous integration tools (like Hudson or CruiseControl). Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

While soapUI supports plug-ins for both Maven 1.X and 2.X, in this article we'll only look at setting up 2.X. The first step is to add the eviware Maven 2 repository to your project (or your settings.xml):


Listing 2: Adding the Maven 2 repository.

Once that's completed, you can add the soapUI plug-in to your pom.xml:


Listing 3: Adding soapUI to your POM.

Once this is done, to run your tests and services, simply use the following:
mvn eviware:maven-soapui-plugin:test mvn eviware:maven-soapui-plugin:loadtest mvn eviware:maven-soapui-plugin:mock

The plugin will load the project file specified in your POM and run all tests available in all TestSuites. You can limit the scope of test execution using the testSuite, testCase and loadTest properties similar to the way we used the switches at the command line above. A full listing of the Maven 2.X plug-in settings are available online.

Next Steps

For more on soapUI, its features and what the soapUI team is working on, checkout the soapUI website. For other articles and blog posts on soapUI, the soapUI team also maintains an "in the news" listing on their website. And for more on JIRA, it's interface and what it does, checkout the Atlassian product website.

About the author: Michael (Mike) Kelly is currently an independent software development consultant and trainer. Mike also writes and speaks about topics in software testing. He is a regular contributor to SearchSoftwareQuality.com and a past president for the Association for Software Testing.

Dig Deeper on Topics Archive