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.
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.
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.
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.
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
This was first published in January 2010