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?

• Test your application (module) even when the External Service is not yet available.
• Your Tests will pass even where there are bugs in the 3rd Party APIs.
• Simulate complex scenarios of responses from the External Service.
• Check if you system calls the External Service API as expected
• You can tests your system under different conditions:
  • Simulating different edge-cases responses from the External API
  • Simulating different time delays in response from the External API
  • External API is not available.
  • External API return different error codes.
  • Simulating different Network issues:
    • Close socket with no response
    • Send bad HTTP data then close socket
    • Send 200 response then bad HTTP data, then close socket
    • Peer connection reset
• Completely isolate your system-under-test to be sure that the tests run accurately and only fail when there is an authentic bug.
  To pinpoint this, the system-under-test has to be tested and not its dependencies.
  This way you avoid tests failure as a result of external changes such as server being rebooted / redeployed or network failure.
• Mock responses can be easily and independently set up for each test to guarantee test data is encapsulate with every test.
  Keep your tests independent, sharing data between tests can be difficult to handle and maintain.

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:

Editing the parameter httpMockServer you can set the 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

• Mock Name: define a name that is representative of this mock.
• Expected Request: in this section you need to define the matching request criteria
  In this simple example we are just matching on the URL, but you can create a complex matching based on URL, headers and body. For more advanced headers and body matching see Http Verify, the same principles applies here.
• Response: in this section we can define the HTTP Response that will be return in case there is a match on the Expected.
  For this you can choose:
  • Mock: in this subsection you can define by hand all the response details.
  • Fault: you can choose to respond with one of the following faults:
    • No fault
    • Close socket with no response
    • Send bad HTTP data then close socket
    • Send 200 response then bad HTTP data, then close socket
    • Peer connection reset
  • Proxy: using this option you can proxy the request to other hosts, probably to the real server.

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

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

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

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

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

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).

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.

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):

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:

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

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.

• Server closes connection before response sent
• Corrupt data sent, then connection closed
• OK response sent, followed by corrupt data and connection close
• Peer connection reset - SO_LINGER is set to 0 causing a non-graceful TCP connection termination.

img 10

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

Proxying

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