MockOperations and Responses

As mentioned earlier, a MockService exposes a number of MockOperations which each can contain an arbitrary number of MockResponse messages; that is, a MockService response actually consists a number of preset responses to change between. Each MockOperation corresponds to an Operation in the WSDL imported in your project. When adding a new MockOperation via the Add MockOperation button on top of the list of MockOperations in the MockService window, you are prompted for which WSDL Operation to mock:

Selecting the desired operation creates a corresponding MockOperation and a default MockResponse to start with.

Double-clicking a MockOperation opens the MockResponses Window for configuring the MockOperation:

It contains contains two areas;

• The top contains the list of contained MockResponse messages, double clicking a MockResponse opens the MockResponse editor (see below). Use the Add MockResponse button in the toolbar on the top of the list to add as many MockResponses as you want.
• The bottom half contains the Dispatch method (which controls how to send out responses)  and the configuration for it (SCRIPT in the screenshot above), let’s have a look at this in more detail.

Scale your mocking more effectively | Try simplified service virtualization with ServiceV

MockOperation Dispatching

Once a request has been received by the MockService and dispatched to a MockOperation, soapUI needs to select the correct response method and return it to the client. A number of different dispatch methods are available from the Dispatch drop-down, let’s have a look at these and how they can be put to use.

• SEQUENCE: this is the simplest dispatch method; responses are selected and returned in the order they have been added to the MockOperation.
• RANDOM: almost as simple, this dispatcher selects which response to use at random, over time all responses will have been returned the same number of times.
• QUERY-MATCH: this one deserves a little more explanation as it is quite versatile for returning different responses based on the content of the request. The configuration panel is as follows:
  
  
  
  The list to the left contains an arbitrary number of queries, selecting or adding one enables the related fields to the right which allow you to specify: 
  
  - An XPath expression to be applied to the incoming response
  - An expected value for the XPath expression
  - The MockResponse to return if the value matches 
  
  So if we want to return a certain MockResponse for some value in the request (for example a predefined search result for some search criteria) we would set up an XPath to select the search criteria, specify which value we are looking for, and then which response to return if the value matches. When dispatching the configured queries the first one that matches will be used. If none match, the response in the Default Response drop down will be returned instead.

• XPATH – This is similar to the QUERY_MATCH but not quite as powerful; an XPath expression is applied to the incoming request and the resulting value is used for selecting which  MockResponse to be returned. In our previous example of search results, we could set the XPath expression to select a search term and then create MockResponses named after each expected value. The advantage being that we don’t need to add new XPath statements for new search criteria, just another MockResponse. The configuration panel is as follows:
  
  
• SCRIPT – as always the scripting option is the most versatile and most difficult to master. Create a script that gets called for each request which should return the name of the MockResponse to use. The script can do basically anything, for example:
  • Run a soapUI Request or even a TestCase and select the response based on its outcome
  • Query a database for response-data and make that available to the MockResponse via the context variable
  • Trigger some external process and select the response based on its result
  • And much more

The MockResponse

The last stop in the MockService object model is the MockResponse, which is a message to be returned by the MockService to the calling client. MockServices can contain custom content, headers and attachments, thus allowing you to simulate any kind of valid (or invalid) HTTP response, and additional scripting possibilities allow you to easily add dynamic content to the outgoing response.

Opening a MockResponse by double-clicking it reveals the following window:

This is basically the same as the standard SOAP Request editor window, but user focus is now on the right  (response) part of the editor. Here you configure the response message to be returned, including custom HTTP Headers and attachments via the inspectors at the bottom, in the same way as you in the request editor configure your request messages.

The left part of the window show the last request actually dispatched to this specific response, with all possibilities to view the incoming HTTP Headers, attachments, etc.

MockResponse Scripting

Apart from the standard scripting possibilities available, each MockResponse can have its own Script for creating dynamic content to be included in the returned message. The Script inspector at the bottom of the response editor is as follows:

In the example above we can see a script that sets a simple sessionid property in the current context, which is subsequently used in the response message via a property-expansion. Obviously the generation of properties for usage in a response could be more elaborate, for example querying a database or reading an external file for the response;