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 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.

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.

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:

<plugin>
    <groupId>eviware</groupId>
    <artifactId>maven-soapui-plugin</artifactId>
    <version>3.6.1</version>
    <configuration>
        <projectFile>${basedir}/src/test/spannersws-soapui-project.xml</projectFile>
        <host>localhost:8080</host>
        <printReport>true</printReport>
        <outputFolder>${project.build.directory}/soapui-test</outputFolder>
    </configuration>
    <executions>
        <execution>
            <id>soapui-test</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>
        </execution>
    </executions>
    <dependencies>
        <!-- soapui plugin fails if you don't explicitly add this dependency -->
        <dependency>
            <groupId>xmlunit</groupId>
            <artifactId>xmlunit</artifactId>
            <version>1.3</version>
        </dependency>
    </dependencies>
</plugin>

 

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.

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>7.2.2.v20101205</version>
    <configuration>
        <stopPort>8081</stopPort>
        <stopKey>stop</stopKey>
    </configuration>
    <executions>
        <execution>
            <id>start-jetty</id>
            <phase>process-test-classes</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <daemon>true</daemon>
                <reload>manual</reload>
            </configuration>
        </execution>
        <execution>
            <id>stop-jetty</id>
            <phase>test</phase>
            <goals>
                <goal>stop</goal>
            </goals>
        </execution>
    </executions>
</plugin>

 

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.