Automating Testing of DataPower Services

Any automated build/deployment process should be accompanied by automated testing. This is required for automated (let alone for continuous) delivery of any application. Services residing in DataPower appliances should also be covered by automated testing. This can be achieved by invoking SoapUI test cases as part of an automated deployment, after all the services have been imported.

DPBuddy, our DataPower deployment automation tool, can be used to import the services and to perform an initial verification of the services’ state, such as making sure that all services are listening on the right ports (see the examples here). After this is done, functional SoapUI test cases could be invoked.
As an example, you can use the following target to invoke SoapUI from Ant:

<target name="run.tests" description="Run soapUI tests for our services">
    <!-- This assumes that soapUI/bin was added to PATH -->
    <condition property="soapui.exe" value="testrunner.bat" else="testrunner.sh">
        <os family="windows"/>
    </condition>
    
    <exec executable="${soapui.exe}"  dir="${basedir}" searchpath="true" failonerror="true" >
        <!-- You can also specify the test suite using -sFirewallTest -->
        <!-- Override host and ports to point to the hosts and pors for this environment -->
        <arg line="-Phost=${dp.url} -Pwsproxy.port=${dp.wsproxy.port} -Pfirewall.port=${dp.xmlfirewall.port} -f testReports -r -j ${script.dir}/soapui/DPTests.xml" />
    </exec>
</target>

This example will run all the tests from soapui/DPTests project and generate reports in JUnit format (-j and -f options trigger the report generation, please refer to SoapUI documentation for the list of command-line options). If you’re running your deployments from Jenkins, you can add “Publish JUnit Test Result Report” post-build action to automatically produce the test report and publish it on the build’s page.

-P option is used to override SoapUI’s project variables to point to the actual ports and hosts for the specific environment, appliance and domain.

DPBuddy supports prefixing environment-dependent properties with the environment, the device or the domain prefix. For example, a port for a Web services proxy could be defined as “dev.dp.wsproxy.port=7096”. You can then use “dp:environment” task to point to the right environment, e.g., “<dp:environment prefix=”dev”/>”. After this task is invoked, a reference to “dp.wsproxy.port” will return an appropriate environment-specific value. You can find more details about the “environment” task in the User Guide.

In the SoapUI example above, we are referencing “dp.wsproxy.port” and “dp.xmlfirewall.port” properties to update the endpoints used in our tests. This allows us to point SoapUI to run the tests against the right environment, the one defined by the prefix.

This approach requires using project properties in SoapUI tests to define endpoints. Thus, an endpoint in SoapUI could look like this:

http://${#Project#host}:${#Project#wsproxy.port}/services/personService


Note that you need to use “#Project#” syntax to reference the properties defined at the project level.

You can see a complete example of an end-to-end build/deployment process, including running SoapUI tests, here.

Using DPBuddy you can also dynamically update backend endpoints in DataPower to point to test applications or to mock services defined in SoapUI. For example, the following target in Ant can be used to update the backend of a WS proxy:

<target name="modify.ws.backend" >
    <dp:modifyConfig >
        <configuration>
            <WSEndpointRewritePolicy name="testServiceProxy">
                <WSEndpointRemoteRewriteRule>
                    <ServicePortMatchRegexp>^{http://personservice}PersonService$</ServicePortMatchRegexp>
                    <RemoteEndpointProtocol>http</RemoteEndpointProtocol>
                    <RemoteEndpointHostname>services-backend-test</RemoteEndpointHostname>
                    <RemoteEndpointPort>7080</RemoteEndpointPort>
                    <RemoteEndpointURI>/services/personService</RemoteEndpointURI>
                    <RemoteMQQM />
                    <RemoteTibcoEMS />
                    <RemoteWebSphereJMS />
                </WSEndpointRemoteRewriteRule>
            </WSEndpointRewritePolicy>
        </configuration>
    </dp:modifyConfig>
</target>

You can also use DPBuddy to automatically upload your DataPower-related files, such as XSLT and JavaScript files, directly from SoapUI as explained in this post.

If you’re interested in automating your DataPower deployments and testing, download DPBuddy and give it a try.