1. Home
2. SOAPUI
3. SOAP UI Mock Handlers

MockServices in soapUI gives you the unique ability to mimic Web services and create/run Functional and Load Tests against them even before they are implemented. Better yet, this allows you to eliminate the expense of building full-scale replicas of your production systems, as well as provide your customers access to your services without having to wait for them to be complete or available. In soapUI, you can create standards-compliant Mocks with virtually no effort on your part : just select a WSDL from your desired location and soapUI automatically generates the MockService and its methods for you. Then populate it with pre-defined responses for requests, customize responses any way you like, and define different responses for a given operation. Use the advanced scripting features to simulate any kind of desired behavior : fixed responses, random errors, dynamic results, and much more.

1. MockService Scripting Overview

A quick recap of the MockService model in soapUI: A MockService contains an arbitrary number of MockOperations, which each mock some WSDL operation in the containing project. These MockOperations can mock operations in different WSDL services, so a single MockService can mock any number of WSDLs to any extent. Each MockOperation contains an arbitrary number of MockResponse messages, i.e. messages that are returned to the client when the MockOperation is invoked. Exactly which message to return is decided by the MockOperation dispatch method, for which several are available; sequence, random, script, etc.

For the MockService itself there are number of scripting events available:

• Start and Stop scripts: These are useful for opening or closing shared objects (for example collections or database connections) which can be made accessible to scripts "further down" in the mock object hierarchy.
• OnRequest script: This is the main handler for simulating non-SOAP behavior (REST, etc); it is called before soapUI does any internal dispatching and has the possibility to return any kind of response to the client (thus bypassing the whole soapUI dispatch mechanism)
• AfterRequest script: primarily intended for custom logging and reporting functionality

2. Mock Handler Objects

A number of objects are commonly available in most scripts; here comes a quick overview with links to their corresponding javadoc:

• context: Used for storing MockService-wide objects, for example database connections, security tokens, etc
• RequestContext: Used for storing Mock Request-wide objects, for example dynamic content to be inserted into the response message
• mockRequest: An object corresponding to the actual request made to the MockService. Through this object you can get hold of the incoming message, its headers, etc. Also the underlying HttpRequest and HttpResponse objects are available for "low-level" processing
• mockResult: An object encapsulating the result of the dispatched request, this is available in the MockService.afterRequest script.
• mockResponse/mockOperation: Objects available at the corresponding levels for accessing the underlying configuration and functionality
• mockRunner: The object corresponding to the execution of the MockService; this gives you access to previous mock results, etc