Using soapUI to mock Web services can offer insight on user acceptance

Many of the inconsistencies in automated integration testing can be put to rest by utilizing mock Web services. In this tip on soapUI, you will learn how acquire and review static responses in user interface testing. These responses can help indicate the look and feel your Web application will have and provide insight in how users will respond and use the application.

This Content Component encountered an error

Michael Kelly
Michael Kelly

While programmers commonly use mock objects to help with unit testing, mock services are often handy for assisting with early or automated integration and system testing. Simple mock services are often setup to return static responses, but now days it's not that difficult to setup mock services that can return a variety of responses based on different request parameters. In this article, we'll look at how soapUI can help development teams quickly mock Web services.

While I most commonly use mock services with test automation, they're also useful for testing works in progress. If you're trying to test your end of an interface before the other end is ready, a mock can be a handy way to keep testing moving along. Using mocks can also allow you to control your test coverage by allowing you to more easily vary the responses you get back. This can be particularly helpful with negative and stress testing.

Editor's Note:
This article was written using soapUI 3.0.1 and uses the Atlassian JIRA SOAP web service as an example application. This web services is used for example purposes only. If you're following along using this article, try the steps on your own web service if it's available.


With a soapUI mock service you can return responses using a variety of methods including: cycled, randomized, or deterministic. Those responses can include attachments or custom http headers. But most importantly, it's fast and easy. The example below builds on the Atlassian JIRA Web service testing example used in the previous article in this series on testing Web service performance.

Creating a mock Web service

To create a mock in soapUI, simply right-click on the interface you'd like to mock and select "Generate MockService." This will open the Generate MockService dialog shown in figure 1 below.

Given that the Atlassian JIRA interface includes 108 operations, for the example we're not going to mock them all. For this example, we'll stick with login and logout. For each operation you select, soapUI will create a generic mock response XML. Listing 1 below shows the response for the mock login operation.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:jir="http://jira.atlassian.com/rpc/soap/jirasoapservice-v2">
<soapenv:Header/>
<soapenv:Body>
<jir:loginResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<loginReturn xsi:type="xsd:string">?</loginReturn>
</jir:loginResponse>
</soapenv:Body>
</soapenv:Envelope>

Listing 1: Mock JIRA login response.

You'll see that for each possible data element, the value has been pre-populated with a question mark. At this point, you can change that value to whatever you'd like and save it. If you'd like more than one response – that is, different responses with different values – just use the toolbars to create more. Using the mock service editor, you can now setup whatever login and logout responses you'd like.

Using a mock Web service

Once your mock service is setup, you can run it be clicking the green start button in the upper-left corner of the mock service editor. The default port for the mock service is 8088; you can change that using the options button on the same toolbar in the mock editor. You'll see two indicators that your mock service is running, one is the continuous progress bar on the mock editor, the other is an animated icon for the mock service in the Navigator tree on the left. You should also be able to view your mock service WSDL in your browser: http://localhost:8088/mockjirasoapservice-v2SoapBinding?WSDL

At this point, if you submit a request to your mock service, you'll see your canned response come back. You can submit a request a couple of ways. Using the mock service editor, you can quickly create a sample request and submit it to see the response come back. Or, you can follow the same steps you used before when you added a WSDL and created a test case. Either way, when you run your first request, you'll see a transaction get added to the Message Log in the mock editor, as shown in figure 2 below.

At this point, you have a working mock Web service. You're ready to start building a variety of responses to support your testing efforts. You can have your service run locally, or you can setup a mock service in a shared development environment that others on the team can access at any time.

For a bit more variety in your responses, if you drill into one of the operations in your mock service, you'll see that you can quickly and easily add multiple responses. As shown in figure 3 below, once you have multiple responses setup, changing to different dispatch methods is as simple as selecting from a dropdown.

Related Content:
Testing rich Web services with soapUI
Master the writing, analyzing and repair of software projects and applications using soapUI in this expert walk-through.

Testing Web services' performance with soapUI
A software application expert shows how to write, implement and analyze load tests using soapUI. Learn how to use this tool and its features to test all application threads.


Once you've selected your dispatch method, if you select an option that requires setup – like script, xpath, or query match – a frame will open allowing you to configure as needed.

Next steps

In this article, we continued our series on using soapUI to test your Web services. In the first article in this series we created a simple functional test for the Atlassian JIRA SOAP Web service. In the second article, we turned that test into a load test and looked at some of the ways soapUI introduces load to Web services. In the final article for the series, we will take a look at soapUI integration with JUnit.

For more on soapUI, it's 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.

This was first published in January 2010

Dig deeper on Automated Software Testing

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close