HTTP Mock

HTTP server to provide configurable mock responses when automating complex scenarios.

Configuring the mocks

Mock logic is not hardcoded into the server, instead it's provisioned just before starting the automated scenario. For that a special endpoint is provided to instruct the server how it should behave.

POST /.mock
Content-Type: application/json

{
    "title": "Correct user status update",
    "delay": [0.01, 0.3, 2, 5],

    "method": "POST",
    "path": "/users/(?P<msisdn>\\d+)/?",
    "when": "user_state <> ''",

    "reponse": {
        "status": 200,
        "headers": {
            "Content-Type": "text/plain",
            "X-Correlator": "correlator-$HTTP_X_USER_MSISDN"
        },
        "body": "you did a $HTTP_METHOD request for $PATH_MSISDN to set a state ${user_state}"
    }
}

HTTP/1.1 201 Created
Content-Type: application/json

{
    "id": "1234"
}

The above will provide the following response when queried:

POST /users/447568116268 HTTP/1.1
Content-Type: application/json
X-User-Msisdn: 447568116268

{
    "user": {
        "state": "ACTIVE"
    }
}


HTTP/1.1 200 OK
Content-Type: text/plain
X-Correlator: correlator-447568116268
X-Mock-Version: 0.0.1
X-Mock-Date: 2015-04-23T10:32:43.123133Z
X-Mock-Id: 1234
X-Mock-Title: Correct user status update
X-Mock-Delay: 0.3

you did a request for 447568116268 to set a state ACTIVE

There is quite a lot going on there, let's see more in detail what every mock request field means:

title: this is just some description of the mock so it's easier to troubleshoot (optional)
delay: choices for the delay on providing a response (optional, can also be a fixed value or a string with a range)
method: to which request methods it'll apply (can be a list)
path: to which request path it'll apply -- also can capture values
when: SQL like query that must resolve to true for the mock to apply to a request
response: defines what will be returned, interpolating values on the defined strings (if null then it just applies the delay)

When a request comes the mock server will match it against the configured mock responses, choosing the most recently configured one among them. If none matches then an error is reported back to the client:

HTTP/1.1 501 Not Implemented
Content-Type: text/plain
X-Mock-Version: 0.0.1
X-Mock-Date: 2015-04-23T10:32:43.123133Z
X-Mock-Error: NO_MATCH

Your request didn't match any configured mock. Here is the list of mocks:

  - Correct user status update

As an extra feature the /.mock endpoint could allow GET/PUT/PATH/DELETE to manage what's on there

To ensure the mock server is low-maintainance it'll be configured with an expiring policy for configured responses, ideally with a hard memory cap but also some clean up of older entries. This simplifies usage since configuring it is an append only operation, no need for clean up the scenario setup.

Querying the mocks

The mock server will remember all the requests being made to it (until they're expired/removed), so it's trivial to query it for them.

GET /.mock/1234 HTTP/1.1


HTTP/1.1 200 OK
X-Correlator: correlator-447568116268
X-Mock-Version: 0.0.1
X-Mock-Date: 2015-04-23T10:32:43.123133Z
X-Mock-Id: 1234
X-Mock-Title: Correct user status update

[
    {
        date: 2015-04-23T10:44:12.888888Z,
        delay: 0.3,
        request: {
            headers: { ... },
            body: "..."
        },
        response: {
            headers: { ... },
            body: "..."
        }
    },
    ...
]

It also allows to filter the results with an SQL syntax using the ?when=sql query param.

drslump/httpmock.md

HTTP Mock

Configuring the mocks

Querying the mocks