What is HTTP Mocks?

Testerum allows you to use mocks in order to create Isolated Quality Automated Tests. Basically, with Testerum 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. In real life, when we develop software we interact with different 3rd Party APIs, even if they are internal or external services. Testerum Mocks can be used for mocking any system you integrate with via HTTP or HTTPS (i.e. services, web sites, etc).

Why to use it?

Some of the main reasons two use Testerum Mocks are : Testing, De-coupling development & isolate single service We will refer strictly to Testing now and present the advantages:

    1.1 Getting started:

    Testerum Mock is an HTTP stubbing application which configured, returns specific responses based on the request. Testerum can perform multiple tests, from simple mocks which are only matching the url, to more advanced combinations of URL, Header and body matches using JSON, REGEX, XPath, XML and many others.

    Testerum allows you to use mocks in order to create Isolated Quality Automated Tests. Let’s see how it’s done. To set our first mock API up and running we have to create a new Test and add the step from HTTP / Mocks library.

    Basically, with Testerum Mocks you open a mock server which will offer you desired responses to particular requests (stubbing) .

    HTTP Mocks open server

    Once you press OK, you are ready to create your first HTTP stub.

    On top of this, useful options come along including communications with other APIs and simulation of different real scenarios.

    2.1 Stubbing responses:

    If you haven’t added the HTTP mock step in a new test yet, create a new test and then: Select from Basic Steps -> http -> Mock

    Given the HTTP mock server <<httpMockServer>> with the mock request <<httpMock>>

    Once you added this step you are ready to create your first HTTP stub.

    Adding Mocks from Testerum steps

    2.2 A first basic stub mapping

    Supposing you have already added the HTTP Mock step from Basic Steps we can carry on configuring the HTTP stub.

    First of all we have to set a port (address) and then to go to HTTP stub, give it a name, choose the method and add the path for the Expected Request.

    Below, for the Response section, set HTTP status code, headers, choose Body Type and add the body text. Usually, we first choose the Body Type – JSON, which automatically will set the Header Content-Type to application/json. Inside the body, write the JSON details you expect to receive when an HTTP call is made e.g. {…}

    HTTP Request and Response over Web

    Save everything and you can test your stub by opening the browser and navigating to that address.

    *Note that in order to keep the server connection open you have to add another step into this test which will keep the connection alive.

    For this we add a new step from: Basic Steps -> debug

    When I wait<<waitDurationMillis>>
    Wait step added in order to keep the server connection alive

    Hit the Save button and Run the test.

    This will open a server (on the port you set, in this case 1211) and will keep the server connection alive for a period of time you specify in the waiting step. Now the server is ready to respond to your requests with the desired responses.

    Local server opened in browser

    3.1 Advanced mocking

    Advanced request matching

    During the development process you will test different scenarios. In this example we will simulate a new to-do item in a RESTful API by mocking a POST request to /api/to-do. Now, to test different scenarios where both success and failure cases are covered, each HTTP request we will execute has to return different responses regarding to the post body we are sending.

    We will select from the list the HTTP method required for this mock to match.

    In order to achieve this, we will add a body matching clause in the Advanced section of the Request window.

    For e.g. : Click on Body, choose from “Body matching” Json Verify and then write or paste the expected JSON expression into the text area.

    *If the content you added into the text area is a valid JSON, a green validation will appear on the right side of the current window.

    Advanced HTTP Mock body request

    Now, let’s dig in into more details about the Request Parameter Clauses.

    Requests can be matched on:

    • Headers
    • Query parameters

    Parameter match clauses can use a set of match operations such as:

    • EXACT MATCH
    • CONTAINS
    • MATCH REGEX
    • ABSENT
    • DOES NOT MATCH
    HTTP Request Match Parameters

    The response to be served

    When multiple match clauses are added a request must match all of them for the response to be served (they are combined with logical AND).

    3.2 Response parameters

    Response status

    The HTTP status code which is sent with the response.

    Response headers

    Headers will be set on the response if necessary.

    Response body

    Additionally, a response body can be written.

    Response status code headers

    5.1 Simulating states with Scenarios

    In some situations different responses are expected to be served when identical requests are made. In our example, we are testing a to-do list application and let’s suppose we want to begin with no-to list elements, post an element then see the element appear in the list.

    We will make an assumption that there is a “list to-do elements” API call used to fetch the list, this will be called twice during the above 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 element 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.

    First empty scenario

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

    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 element added” state:

    First scenario content

    5.2 Testing

    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.

    Example of how to start testing

    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 element 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 all about scenarios"
          }
        ]
    }

    6.1 Simulating Faults

    These are configured per stub, so it is possible to respond to specific requests with a fault.

    Here and now, 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.

    n Testerum, you can simulate different faults when responding to requests such as:

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

    These faults can be configured when creating or modifying a stub by choosing the Fault tab and selecting the fault type:

    HTTP Request and Response over Web

    7.1 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 inevitable variabilities, and tested to ensure they behave conventional when conditions aren’t met.

    It’s very important to check especially that timeouts work as expected, and end user’s experience is preserved.

    HTTP Request and Response over Web

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

    HTTP Request and Response over Web