SoapUI is a very useful tool to test web services, but it can also be used to mock a web service, so you can test service clients as well. We’ve used this at my current client for a couple of reasons:
- The real service is not available for some reason
- A particular response from the service is needed for testing. QA has used this extensively on a couple of projects I’ve worked with.
In this brief tutorial, I’ll walk through setting up the mock service in SoapUI and making calls to the mock service. I’m using SoapUI 3.0.1 in case the screens look a little different. I’ll attach the sample WSDL that I used in this tutorial, in case it’s helpful.
Set Up Mock Service
In order to set up the mock service, you’ll need a complete WSDL document defining the service. Don’t worry about the endpoints defined in the WSDL; it is the schema and operations that are most important. You can configure most of the rest.
- Launch SoapUI, and select File: New SoapUI Project from the menus.
- Give a name for your project, and enter the path to the WSDL document describing the service you’re mocking. Note: You don’t need to have the file on disk; a URL works just fine. In fact, if you’re mocking an existing service, I’d recommend using the URL for that service’s WSDL if possible, to better ensure your mock satisfies the published contract for the service.
- Uncheck the Create Requests box.
- Check the Create MockService box.
- Click OK.
Here is a screen capture of the sample I’m using in this tutorial:
SoapUI will churn for a moment, loading and reading the WSDL to determine what operations are available for mocking. Once complete, another dialog box will appear allowing you to configure which operations will be available in the mock, and what path and port the mock service will be listening on.
- Check whichever operations you want available in the mock service.
- Change the path to whatever you’d like. The default value will work fine, but you might want to change it to better match the endpoint of the service you’re mocking.
- Change the port to any unused port you’d like.
- The rest of the defaults are fine.
Here’s a screen capture of my sample:
You’ll then be prompted with another dialogue box asking for the name of the mock service. Call it whatever you’d like. This is just for tracking; it is not used to access the mock or make calls to it.
Your new project will now appear in the project listing. It will have two sections, as shown below. One part will list potential operations to make calls against (using SoapUI as the client submitting the request). The other part will contain details about the mock service you’ve created:
Note that the hourglass icon by the service name is greyed out, indicating it is not currently running.
Running the Mock Service
To describe the particular behavior of the mock, double-click on the response for the operation you’re working with. An editor will appear with a sample response, generated from the WSDL document. Modify this response to give the behavior you desire. You can validate the response at any point by pressing Alt-V.
Here is a screen capture from my sample:
To start the service, right-click on the service name and select Start Minimized from the options. The hourglass icon will now be animated.
Calls to your mock service can be made to the endpoint http://soapUI-machine-location:port-you-specified/path-you-specified. For example, assuming I was making calls locally, the endpoint for my sample would be http://localhost:8088/doMathStuff
Calls made to the operation whose response you’ve edited will receive that response. SoapUI will display the latest request to that operation in the Last Request tab of the response editor. This can be useful to verify your client is behaving as expected.
Calling the Mock Service
The mock service can be called like any other SOAP service. I’ll provide an example using SoapUI as the client, but we’ve used several different clients written in multiple web service frameworks to make these calls.
When the WSDL was read to create the mock service, a section for requests was also created in the new project. I’ll be using that for convenience, but you could create a new project using the same WSDL to give the same result.
- Add a new request to the operation you wish to call. In my example I’ll name it Test Request. SoapUI will autogenerate a sample request per the schema for that operation.
- Modify the SOAP request as you wish.
- In the test request editing window, specify the endpoint of the mock service.
Here is my test request, configured to call the mock service:
Here is my SoapUI workspace before making the call to the mock service. You can see the test request (with no response showing) set to send to the localhost endpoint, and the mock response (with no latest request yet).
Here is the same workspace after sending the request. If the two windows look the same, they should! The test request window is showing that it received back the response the mock service has configured for the Add operation, and the mock response window is showing that the last request it got was the one from Test Request:
Note: SoapUI allows you Groovy programmatic access to various events in the request/response lifecycle. I’ve not used this yet, but it looks like you’d be able to create more generic responses for testing, rather than having static text in your mock response. There are also a lot of things that can be autogenerated for testing; it’s quite the tool.
FYI: There is a SoapUI plugin available for most IDEs, so this same behavior can be accessed from your development environment if you’d like. I tend to run it separately so that I can better assist the testers through any difficulty in getting the mocks set up in their environment, though.