What are HTTP Mocks?

In order to create quality tests you need to isolate the system under test from using 3rd party APIs. For this Testerum HTTP Mocks is what you need. Basically, with Testerum HTTP Mocks you open a mock server which will serve you desired responses to particular requests (stubbing) . On top of this, useful options come along including communications with other APIs and simulation of different real scenarios.

Why to use it?

Getting started

Testerum Mock will start a separate server on a specified port and will returns specific responses based on the request. In order to create a HTTP Mock you need to use the following step in your test:

HTTP Mock Step

Editing the parameter httpMockServer you can set the mock server port.

Set HTTP Mock Server port

NOTE: In order for your tested application to use this mocks you need to point your application to use this mock URL and PORT. Editing the httpMock parameter you can define the matching criteria for the HTTP Request and what will be the HTTP Response.

img 3
Simple HTTP Mock

When you define the mock details you have to set the: (img 3)

How to debug

A simple trick to test a mock step is to add an extra step: Basic Steps → debug → When I wait<<waitDurationMillis>> and set a waiting time quite big, something like 30.000. (img 4)

img 4
Simple HTTP Mock

This will open a server (on the port you set, in this case 12312) and will keep the server connection alive for a period of time you specify in the waiting step (in this case 30 seconds). Now the server is ready to respond to your requests with the desired responses. You can use the curl command, browser or some other tool to check the matching and the response of the mock.

img 5
Simple HTTP Mock

Simulating State with Scenarios

In some situations different responses are expected to be served for a sequence of identical requests. In our example, we are simulating an external API that manages a TO-DO List application. Our TO-DO List API will be called twice during this test example which will return no elements for the first call, and for the second call will add an element in the list. For Testerum Mocks to differentiate the first and second cases (both requests have the same URL, method, request headers) something additional is required. Testerum Mocks Scenarios comes with a solution by offering finite state machines that can be used as optional stub matching conditions. Based on the current state of the machine more than one definition of an identical stub with different responses is allowed. Example: To apply the above case, we would affirm that the stub returning the empty list is only matched when the scenario is “Started”, while the stub which responds with the list with one element is only matched when the scenario is “First item added”. Let’s start by generating the empty list stub, which is matched only when the scenario named “To do list” is in the “Started” state.

img 6
First empty scenario

Then generate a stub which manages the "Add the first element in the list". When executed, this stub will move the scenario state to “First item added”:

img 7
HTTP Request and Response over Web

Another stub is required to return the list which contains one element. This stub is matched only when the scenario is in the “First item added” state:

img 8
First scenario content

Testing Scenarios using CURL

For testing purposes, we have to add a waiting step at the end of our test in order to keep our server open for a given period of time (in this case 30 seconds).

Waiting step

If the connection with the server is alive we can start testing, serving requests to our server. First, make a GET request to receive the list, which should not contain any elements.

$ curl http://localhost:1211/todo-items
    "elements": []

Secondly, to add a new element, execute a POST request at the same URL (since we didn’t specify a body matcher in the stub, it doesn’t matter what the request body contains):

$ curl http://localhost:1211/todo-items -X POST

Now, doing a POST request, we should have moved the scenario state to “First item added”, and when we execute another GET request, the list of elements should now return on element:

$ curl http://localhost:1211/todo-items
    "elements": [
        "id": "1",
        "details": "Learn about Scenarios"

Testing Scenarios using Testerum

One easy way to test your Mocks and Mocks with Scenario is to add some extra step to trigger the HTTP calls and see if you get the responses you expect. In the next example we are going to show you all the above Scenario Steps and the HTTP Requests to test them.

img 9
First scenario content

Simulating Faults

Real-world APIs and the networks used to interact with them are prone to failures in ways that can destabilise your application. These cases are hard to cover and to test.

In Testerum, you can simulate different faults when responding to requests such as: These faults can be configured when creating or modifying a stub by choosing the Fault tab and selecting the fault type:
img 10
HTTP Request Fault Simulation

Response Delays

For a multitude of reasons, calls over a network to an API can be delayed. For e.g. network congestion or excessive server load. Applications must be designed to handle network problems, and tested to ensure they behave as expected. It’s very important to check especially that timeouts work as expected, and end user’s experience is preserved.

img 11
HTTP Mock Response Delay


Testerum mocks offers you the option to selectively proxy requests through to other hosts. For testing reasons, it can be helpful to pass some requests through to it when working with an existing API. Let’s take a real case when an API is not yet fully implemented but still testing progress can be achieved for the calling application by stubbing the parts not yet finished. In addition, proxying a selection of requests allows testing of the edge and failure cases that would be difficult to imitate in the target API.

img 11
HTTP Mock Response Proxy