26 September 2007 - 1.7.6 home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge






Mock Responses

A MockResponse holds an actual response to returned from a MockOperation. The response can be configured in regard to response content, http headers, attachments and dynamic processing using groovy (for example to process the input or read data from some external source).

MockResponses are added to a MockOperation from their popup menu or from the Request popup/editor with the "Add to MockService" action/button.

MockResponse Actions

Right-clicking a MockResponse node in the navigator or in the MockOperation editor shows a popup menu with the following actions:
  • Open MockResponse Editor - opens the MockResponse Editor, see below
  • Add to TestCase - prompts to add a corresponding MockResponse Step to a TestCase
  • Open Request - prompts to open the editor for an existing request for this MockResponses MockOperation with the correct local endpoint.
  • Clone - prompts to clone the MockResponse
  • Rename - prompts to rename the MockResponse
  • Remove - prompts to remove the MockResponse
  • Online Help - displays this page in an external browser

MockResponse Details Tab

The bottom left details tab for a MockResponse displays the following properties:
  • Name - the name of the MockResponse
  • Description - an arbitrary description of this MockResponse
  • Message Size - shows the size of the current response message content (in characters)
  • Encoding - the encoding to use for the content of the MockResponse message.
  • Enable MTOM/Inline - enables MTOM/Inline processing for MockResponse messages in the same way as descrbibed for Request Attachments
  • Force MTOM - always returns MTOM packaged responses, even if there are no MTOM attachments in response.
  • Enable Multiparts - enables multiparts in the same way as described for Multipart Attachments
  • Encode Attachments : Tells soapUI to automatically encode attachments that have a corresponding WSDL part with the xsd-type set to either base6Binary or hexBinary.
  • Strip Whitespaces : Strips outgoing responses of any unneccesary whitespaces and xml comments, required by some servers.
  • Remove Empty Content : Removes empty elements/attributes from outgoing responses.
  • Response Delay : Waits the specified number of milliseconds before returning the response.

The MockResponse Editor

Double-clicking a MockResponse in the navigator or MockOperation editor opens the MockResponse editor as seen below:

This editor is more or less a copy of the standard request editor, but shifts focus to the right-hand response area where the MockResponse is configured. The left hand request area shows the latest request handled by this MockResponse, including its HTTP Headers and Attachments.

The Response Area contains the same XML Source editor, HTTP Headers tab and Attachments tab as in the Request Editor (but now all editable). Additionally, a "Response Script" tab is available that displays a groovy script editor for creating scripts that should be executed before returning the actual response content (see more below).

MockResponse Editor Toolbar

The toolbar at the top of the MockResponse editor contains the following actions (left to right):

  • Open Request - Opens a new/existing request that can be issued to this MockOperation when its MockService is running, the request will have the correct local endpoint set automatically.
  • Recreate Response - Prompts to create a default response message from the associated WSDL/Schema definition
  • Create Empty Response - Prompts to create an empty SOAP response message
  • Create SOAP Fault - Prompts to creates an empty SOAP Fault, if the operation being mocked defines any faults, soapUI will prompt for which of these to generate en default detail element;
  • Toggle Layout - toggles between the available split/tab layouts as described in Editor Layouts.
  • Online Help - shows this document in an external browser.

Response Scripts

The "Response Script" tab shows a standard groovy editor for a script that will be executed prior to returning the configured response message, opening for the possibility to create response specific scripts that can dynamically create content of the outgoing response.

The script has access to the following objects:

  • log - a standard log4j Logger for logging arbitrary information to the groovy log
  • context - an instance of MockRunContext that can hold dynamically user-defined properties. The context is service scoped, ie shared between all MockOperations/MockResponses for a MockService during its lifetime. Since this object implements the Map interface it can be accessed using groovy's built-in collection support (see example screenshot above)
  • requestContext - an instance of MockRunContext that can hold dynamically user-defined properties. The context is request scoped, ie is only available during this request and not shared with other mockoperations. Use this to pass values from the dispatch script to the handling MockResponse. Since this object implements the Map interface it can be accessed using groovy's built-in collection support.
  • mockRequest - an instance of WsdlMockRequest which provides access to request-related objects, including the underlying HttpServletRequest/HttpServletResponse objects
  • mockResponse - an instance of WsdlMockResponse which provides access to the current MockResponse object (for example for dynamic manipulation of attachments)

The Run button in the script toolbar will attempt to run the script, setting the context to either the currently available context (if the MockService is running) or an empty one. The mockRequest will be set to the last handled request if available.

Properties set in the context can the be used using standard property expansion in the response, for example the following script:

context.randomValue = Math.random()

creates a "randomValue" property which can then be "used" in the outgoing response:

<detail>${randomValue}</detail>


Next: Usage Scenarios