Basic MockMotor Concepts

MockMotor is a mock engine for APIs a.k.a. web services.

It supports REST, GraphQL, Websockets, and SOAP or XML services.

Mock services save money on repeatitive testing, especially in load testing.

MockMotor Instance

MockMotor instance is a server process that runs on a Linux or Windows box.

It provides mock services' endpoints and a built-in UI to configure them.

Cloned Instances

A single MockMotor instance can support a large number of mock services.

However, for even larger volumes, you can set up cloned instances and share the load between more hardware. The cloned instances sync the configuration from the admin instance and expose the same mock endpoints as the admin instance.

Mock Environments

A mock environment is a set of mock services.

It is created for a project or release, and is defined by a dedicated pair of ports - one for plain HTTP traffic and one for HTTPS.

Mock Services

Mock service is an emulation of a real API.

Each mock service has its own unique URL within the mock environment and can contain several reactions. For example, below is a list of mock services located within an “Example Mock Services” mock environment:

How to Point Application to Mock Service

To point an application to a mock, you need to set the mock service URL in the application’s configuration.

The mock service URLs are specified right under the service name. You can copy it by clicking on the copy icon to the left from the URL:

Mock services do not require any authentication.

However, if your service must work over HTTPS, you may need to either configure a valid certificate in the MockMotor instance settings or add MockMotor’s self-signed certificate to the calling application’s trust store.

Mock Reactions

Mock reactions are scripted responses within a mock service.

A single reaction is selected for every incoming request based on request properties.

Each mock reaction in service is tried in turn until a match for the request is found.

MockMotor can match a reaction to a request using:

HTTP method
Relative URI
SOAPAction header
GraphQL properties
The first element of the XML payload
XPath expressions
JSONPath expressions
JS scripts
…as well as their combinations.

The response payload can be static or generated dynamically by a script. Response properties, such as HTTP status HTTP headers, can also be static values or scripted.

The response delay can be configured to mimic live system response time profile.

For more complicated scenarios, a reaction can forward the request to another endpoint or even spawn a delayed request to simulate background processes.

To support stateful tests, a reaction can also update the values of the selected mock accounts.

Mock Accounts

Mock accounts are similar to real accounts in real environments. Every mock account is a set of key-value properties, where the value can be an account number, current balance or anything that can affect the script-generated responses.

Mock accounts can be selected for specific reaction execution based on the request properties (for example, the account number in the payload).

Mock accounts are bulk-edited in Excel. They can also be updated by the reaction script to support stateful scenarios such as registration.

Variables

Variables hold various context values during the request execution.

Some variables contain values from the incoming request, some from the selected accounts and some even have meta-information about the service, reactions and ready-to-use random values.

Variables are available to all reaction’s scripts when computing their response payload, HTTP status, delay, or any other property.