Web service testing with soapUI

In my previous post regarding Spring-WS and Security I didn’t mention anything about testing the resulting SOAP service. Particularly when it comes to secure services, it’s vitally important to test. First, we want to make sure that the service is functionally correct – that it returns the correct results. Second, we want to make sure it is secure – that it refuses service to any request that does not meet our security requirements.

With regard to how we test, it’s simplest to use some SOAP editor tool that lets us fiddle with the request and press a button to retest instantly. But ideally we want some programmatic test that can be included in the test phase of our build.

This post describes testing the now legendary Spanners WS demo with the following requirements:

  1. Tests must be functional – they test what the webservice does
  2. Security is tested
  3. Tests can be tweaked and rerun instantly
  4. Tests can be included in build process

The updated source of the Spanners WS demo including the tests described here is available to download.

What you will need for this demo

  1. soapUI
  2. soapUI Maven plugin
  3. Jetty Maven plugin
  4. A flask of weak lemon drink
  5. A SOAP service (or any service compatible with soapUI) to test (say, the Spanners WS demo)

soapUI

soapUI is an essential free tool for testing SOAP and other web service protocols. You can load your WSDL service contract into a soapUI project and it will generate sample requests. These requests can be tweaked in an XML editor and submitted to your service. It displays the service response in another editor.

soapUI request / response window

soapUI was particularly useful for testing the SpannersWS demo as it works well with WSS. You can define Security Configurations (right click on your project and click Show Project View) containing username / passwords, signatures, encryption settings and so on for the request and the response. These configurations can be attached to your request. soapUI will add the security headers to the outgoing request and decrypt the response according to these configurations.

soapUI request / response with security configurations

So that’s taken care of most of our testing requirements already. All we need to do is automate this and attach it to the build process.

Creating test suites in soapUI

soapUI allows creation of complex test suites in addition to the simple click-to-test interface. After you’ve demonstrated that your service works using click-to-test, you can add the test request to a test suite. Assertions can be made on the response to test schema compliance, WS-Security status and values of individual elements using XPath selections.

soapUI test with assertions

Each test scenario can be included to form a complete test suite of your service. In this demo, I included a number of scenarios based on WSS:

  • Security pass
  • Missing security header
  • Missing signature
  • Invalid signature

For each scenario, assertions were made on the success or fail state of the response.

Running the test suite from Maven

The soapUI project now contains a complete test suite for our service. The complete suite can be run at any time from soapUI TestSuite Editor. However, we ideally want the test suite run as part of a Maven build. This is reasonably easy to do using the soapUI Maven plugin. I’ve attached the plugin execution to the test phase of my build:

 

The only fiddly bit here is that it we require our webservice to be running so that soapUI can test it. Once again, the fabulous Jetty Maven Plugin is just what we need. We can attach the ‘run’ goal to our process-test-classes phase and the ‘stop’ goal to our test phase. In this way Jetty will start up just before tests are run and stop just after tests are run. Note though that as both the soapUI and Jetty plugins are bound to the same phase (test) we must declare the soapUI plugin before the Jetty plugin so that the soapUI tests run before Jetty is stopped.

 

Our soapUI tests suite will now be run on execution of the Maven test goal or any goal that depends on test – package, install etc.

Unit test or integration test?

I’ve bound our soapUI tests to the (unit) test phase of the Maven build although it’s more often bound to the integration-test phase. The choice of phase here is largely semantic and I don’t really care so long as the tests are run.

I’d argue that what I’m doing here fits more neatly with the idea of unit testing rather than integration testing. I’m specifically trying to test my SOAP service and my Spring-WS config. I’m not testing anything else in my stack nor am I deploying to a realistic environment. Where I test like this, I’d usually stub the DAOs and business logic layers that sit behind my web service. I’m not interested in testing them and I’m not interested in realistic test data.

However, one could follow a similar recipe using soapUI to fully integration test a web service. That is, the webservice and all dependent code would be built (and individually unit tested) and then deployed to a realistic environment (perhaps using the Cargo plugin bound to the pre-integration-test phase) including a test database. We’d simply bind the soapUI plugin to the integration-test phase to use soapUI to run full integration tests.

In this case, we could write our soapUI integration tests to test more than just the SOAP responses. We could also test data integrity and response times for example. We could even go as far as load testing at the integration test phase using loadUI – also from Eviware. I think that’s for another day though.

6 Comments

  • Alex
    November 17, 2011 - 2:28 pm | Permalink

    Hi, Im currently having problems with this example, in setting up SoapUI with the correct security settings. The request goes out encrypted but the response Im getting from the spannersws app has a Fault element stating: “Security processing failed (actions mismatch)”.

    Could you provide some assistance?

  • November 17, 2011 - 7:24 pm | Permalink

    Alex, you should just be able to import the spannersws-soapui-project.xml included in the SpannersWS download. You shouldn’t need to tweak anything to make it work.

    That said, I did have problems with this in the latest version of SoapUI (version 4.0.1) so you may want to try using an older version. I’ve tested this using SoapUI version 3.6.1. It’s still available from http://sourceforge.net/projects/soapui/files/soapui/

  • Pragun
    August 14, 2013 - 11:09 am | Permalink

    brilliant example Stevie, many thanks
    it works flawlessly with soapUI 3.6.1

    – pragun.

  • Pragun
    August 14, 2013 - 1:21 pm | Permalink

    one thing i noticed is when EndPoint.java executes, it unable to get the value ‘id’ i.e.
    String id = xpath.valueOf(message);

    so, the response message doesn’t contain id
    ws:id
    ws:name Spanner
    ws:size 42

    does it mean, there is an issue in decryption or its xpath problem ?
    XPath xpath = XPath.newInstance(“//ws:id”);

    thanks,
    Pragun.

  • tom
    August 1, 2014 - 1:51 pm | Permalink

    hello .. this is a nice article. thanks. My problem is that when i execute a request in an wsdl, soapui give me a response the same as request .. do you have any idea of this problem ?!

  • August 4, 2014 - 7:19 pm | Permalink

    Not sure what’s going on there Tom. Be aware though that when you double click on a request for your service, the request message is shown to you to edit. It’s only actually sent to the web service when you click the green submit button. Then the request message is then still shown on the left and the response is shown on the right.

    Remember also that this article is a few years old now. I was using SoapUI version 3.6.1 for this. I believe it’s moved on a couple of major versions since then and its usage may have changed.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *