I am on a two-man team that has been hired by a client to test one of the 3rd party’s (3P-A) Web Services with another one of their 3rd (3P-B)party’s Web Services. The way we will be testing these services is via SoapUI.

I have used SoapUI on previous projects, but it was at a very, very basic level (simple mocked requests and verify responses visually). For this client, we want to perform verification (assertions) programatically, and perform load testing. Their services are still in progress, and we will need to Mock both 3rd party services from their provided WSDLs.

  • What this article covers:
    • Project setup
    • Basic Properties
    • Test Suites
    • Assertions
    • Request/ Response configuration
    • Load Testing
    • Mock Services

  • What this article does NOT cover:
    • WS-Security
    • High volume Transactions
    • Integration with Ant and TestNG (future article)
    • Groovy Scripting


Overall, this tool has been very helpful at every client. There are some shortcomings, which I point out, but so far it is the easiest of all the other Web Service testing tools (JMeter, Grinder) to get started with. It may not be as robust as others, but so far it appears to be the easiest to use.

Project Setup

You will need

– Eclipse

– JDK 1.5+

– Tomcat 5+

– SoapUI 2.5.1

  • SoapUI 3.0 is coming soon, but we will use 2.5.1

With the help of some service code I found online ( I have created my own services and put together two simple WSDL operations for us to test.

Download the service code <link>, and import it into an Eclipse project. Once you have the project in your workspace, place the build.xml file into the Ant window. Open the build.xml file and replace the tomcat.dir with your Tomcat instance’s location.

You can now deploy the service’s war file by following these steps: double-click the “deploy” Ant target, start Tomcat, and navigate to http://localhost:8080/jaxws_example_1/services/order?wsdl. If you see the WSDL, everything was setup successfully. If you see errors, you may want to verify that your port number is correct within Tomcat’s /conf/server.xml file, and you may want to start over from scratch if problems persist.

SoapUI Setup

Open SoapUI, and from the menu, select File-> New Soap Project. Give your project a name (e.g. SoapProject_1), and for the WSDL location, put: http://localhost:8080/jaxws_example_1/services/order?wsdl. Make sure that the 3rd check box from the top is check, which will automatically create your Mock Service. A couple more pop-ups will appear because we have checked these check boxes, but simply click “OK” on each of them (the defaults are what we desire).

One of the more annoying nuances of SoapUI is that it does not automatically save your updates. You must save them automatically. Push either Ctrl-S or the save symbol near the top left of the window, and save the soapui-project.xml file (use its default name) to your desired location.

Your SoapUI workspace should now look like the following:



Properties are project variables, which can be set at any level of your project.

Double click on the top level node (SoapProject_1) of your project, which will bring up the project’s configuration window, and select the “Properties” tab on the bottom left. From here, select the “Add a property to the property list” button.


Name your property “DefaultOrderServiceEndpoint_Property”, and give it the default location of: http://localhost:8080/jaxws_example_1/services/order. In the future, you can reference this property via: ${#Project# DefaultOrderServiceEndpoint_Property}. This will be a handy property, which will allow us to easily change the endpoint our tests are pointing at.

For example, if a WSDL has been agreed upon by the client and service dev teams, the client dev team can use SoapUI to Mock the services (more on this later) and not lose time while the service dev team is still in progress. The client team will then update this property to point to their Mock Service instead of the default endpoint value. They will also be able to mock the responses coming back from the Mocked Service method calls as well (more on this later too).

Test Suites

A Test Suite is a group of tests that can include any number of “Steps” that can be be run together in one execution, or individually in isolation. There are two types of tests: Functional Tests and Load Tests.

– Functional Tests

Right-click on the top level node for the project (SoapProject_1), and select “New Test Suite”. Next, right-click on the newly created Test Suite 1, and select “New Test Case”. This will bring up a window where you can add steps to the test. Let’s add a new request step by right-clicking on the “Test Case 1”, and give it the name “placeOrderTest”. Then select the placeOrder method from the drop down list, and select all of the check boxes before you select OK. You can now run the test by right-clicking on the Test Suite 1, select “Launch TestRunner”, and select OK.

You probably noticed that our tests did not pass all of the Assertions (more on Assertions later). This is because the default character of choice by SoapUI is a single “?”, which threw a fault when it tried to convert the price into a number. We now need to go into the request and add some additional valid dummy data to all fields.


We also want the endpoint to be configurable by using a property, which we created earlier. Click on the drop down URL at the top center of the window above and select “Add new endpoint”. Set the endpoint to the Project property we created earlier: “${#Project# DefaultOrderServiceEndpoint_Property}”. This will allow you to set the endpoint at the global level for the tests.

If you would like to add additional steps to the Test Case, simply right click on the test case and select “Add Step”. Try and add the delayForProvidedNumberOfSeconds() method to the Test Suite, and run both Test Cases at once. Don’t forget to set the endpoint to point to the Property we configured earlier.

Note: Another problem with SoapUI’s implementation of the Test Suite feature is that it completely ignores Load Tests that exist within the Test Suite. I understand their logic for this, and can easily see where it could be annoying to run load tests along with your function tests, especially when some load tests can take a great deal of time. However, I wish they would have separated the Load Tests into their own suites, so I could run all of my Load Tests together in one execution.

– Load Tests

Under our “Test Case 1” node, there is the sub-element: Load Tests. Right click on this sub-element, and select “New Load Test”. By default, it includes the Test Steps already provided in the Test Suite. You can now tweak the settings as you see fit in order to Load Test your services. Please see the SoapUI documentation on the different Load Test settings and strategies:

Note: The Burst Strategy does NOT work in the 2.5.1 version of SoapUI. In a forum thread that I started, they said that it should work in the nightly releases, but I checked out the and it did NOT work in that release either.

Update: The nightly build has been fixed as of 6/05, and will be included in the 3.0 release.


Assertions can be applied at almost any level within a SoapUI project. As you have already seen, we had SoapUI generate a few Assertions in the last section when we setup our Test Suite.

The two most likely places you will use assertions:

– Load Testing:

– Test Cases:

Mock Services

SoapUI allows you to create your own Mock Services from a given WSDL, which will allow you to customize the responses to certain requests. Since we created these Mock Services when we first setup the project (one of the checkboxes from earlier), all we have to do now is set the services port and then start the services.

Double-click on the “DefaultOrderServicePortBinding Mock Service”, and then click on the options icon next to the green arrow (looks like tools). Set your port to 3033, click OK, and then click on the green arrow. Your Mock Service is now up and running. Adjust the Property that we set earlier in this article (DefaultOrderServiceEndpoint_Property ) to use port 3033 instead of the default.

One of the more annoying aspects of SoapUI is that you can start the Mock Services externally (outside of the GUI and outside the console), but you cannot stop it. The reason I wanted to start and stop this manually was in order to avoid starting SoapUI every time I wanted to run my tests against Mock Services. I had to abandon this flow, and just settle for starting and stopping my Mock Services manually. It appears that no fix for this flow is on the candidate list for near-future releases:

In Conclusion

I will definitely use the SoapUI toolkit on my next Web Services project. The ease of use is its most appealing aspect, and I really like that it integrates with Ant. The ability to run the tests that I create in SoapUI from within Ant is a huge benefit. This reduces my time and effort to write these tests, and allows for better test coverage of the exposed WSDL operations.

One of its biggest disappointments so far is its extremely basic Graphical display for the Load Test data. This is very archaic, and some basic updates could go a very long way. (e.g. put metrics on the left and bottom parts of the graph)