06 August 2007 - 1.7.5 home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge






soapUI Pro MockResponse Step

soapUI Pro includes a MockResponse step that listens/waits for a SOAP Request and returns a preconfigured response before moving on. The incoming request can be validated just as the response of a TestRequest Step with the same configurable assertions.

Usage scenarios for this TestStep are for example:

  • Client testing - validating incoming requests and returning dummy/incorrect responses to test a clients behaviour
  • Testing of asynchronous processes - for example starting some kind of job with an initial RequestStep and then waiting for a notification before moving on

Creating MockResponse Steps

MockResponse steps can be created either "from scratch" using one of the TestCase/TestStep Insert/Add operations;

The dialog contains the following options:

  • Name - The name of the created step
  • Operation - Specifies which operation to mock
  • Interface - Specifies which interface to mock, changing this will also update the list of available operations
  • Create Response - if a default MockResponse message should be created from the schema
  • Port - the port to listen on
  • Path - the path to listen on

After setting the desired values and selecting OK, the step will be created and its editor opened.

Other ways to create a MockResponse Step are:

  • From an Operation Nodes' right-click menu to create a MockResponse step for that Operation

  • From a Request Nodes' right-click menu to create a MockResponse step for that Request, using the last response as the MockResponse content (if available).

  • From a MockResponse Nodes' right-click menu to add it to a TestCase, using the existing MockResponse content (if available).

The MockResponse Step Editor

The MockResponse Step is the basically the same as the standard MockResponse editor with the addition of the same assertions/log tabs in the bottom as the TestRequest editor and a number of context-sensitive wizards in the Outline Editor for creating assertions and Property Transfers.

At the top there is a toolbar that adds input fields for the path and port to listen on during execution, the rest is the same as the MockResponse editor. These are grayed out during execution of the MockResponse step. Assertions can be added/managed just as for the TestRequest editor, the list of available assertions is the same except the SOAP-Fault-related assertions, which are not applicable to request messages.

MockResponse Step Execution

When the execution of a TestCase reaches a MockResponse Step, the step will start a local temporary MockService and wait for a request to the configured operation on the configured path and port. Onces a request has been received, it will be validated with the configured assertions and processed just like a standard MockResponse. After returning the MockResponse result, the MockService will be closed down. and execution will move to the next step in the TestCase.

Property Transfers can be used with MockResponse Steps just as with TestRequests, ie properties can be transferred from incoming requests and to outgoing responses.

Although running a LoadTest containing MockResponse steps will work, these steps are not designed for LoadTesting due to the following:

  • A MockService is started and stopped for each time the MockResponse step executes. If the request to the temporary MockService comes in before it has time to start, it will get a standard 404 error message back.
  • If there are several threads running/waiting for a request, in which order should soapUI dispatch incoming requests to these? Currently soapUI only starts one MockService at a time, the first thread to get to the MockResponse step gets to wait first. Susbsequent steps will need to wait until "their turn".

MockResponse Response Scripts

The context script variable available in the MockResponse Response Script, acts both as a MockRunContext and a TestRunContext, allowing it to access the same context variables as other groovy scripts in the TestCase


Next: DataSource Step