Open-Source Testing Tools for API Development – Backend Testing

Author: John Ormerod, W3Partnership Limited

Date: July 2017


In part 1 of this series, I covered my experience with:

  • API Definition
  • Unit Testing.

In part 2, I covered:

  • Calling APIs: Test Clients

This will be followed by two more instalments:

In part 3, I covered:

  • Function and Load Tests
    • SoapUI
    • JMeter

In my final instalment, I cover:

  • Part 4
    • Mocking back-end services

Some of the tools were recommended by colleagues on projects, some I discovered and the rest were mandated for use on a particular project.

Mocking Back-end Services

When your development involves calls to http servers / services, both unit and functional testing usually requires some form of mocking of the servers, so as to make the tests consistent and repeatable – especially when it comes to testing exception conditions. If you search for such tools, you will find several. On a recent project, the tool being used was Wiremock – whose use I describe here.


Code and guidance can be obtained from WireMock Home.

WireMock can be integrated into JUnit as an alternative to using mocking extensions such as Mockito, which can be very time-consuming to define. See How Java developers can use the Wiremock framework to simulate HTTP-based APIs for a comprehensive introduction to using WireMock with JUnit.

The use that will be described in this section, is that of a stand-alone substitute for a real server (or service). The following diagram, shows this in a very clear way, and is taken from WireMock: Mock Your REST APIs.

This article also provides a good guide to setup and use, that augments this section.


Download the latest executable jar from the WireMock home and place in a suitable location, such as C:\Apps\WireMock.


Launch it with the following command:
java -jar wiremock-standalone-2.4.1.jar –root-dir e://data/WireMock –bind-address localhost –port 9090

root-dir is the location of the ‘mapping’ definitions, which will be explained below.
bind-address is the ip address that WireMock binds to
port is the port to be used (8080 is default)


When using WireMock, it’s as if it is intercepting calls to the real service. This is done by substituting the ‘hostname’ or ‘ip address’ part of the URL with that of WireMock. In the section on Calling APIs, a postcodes API was called: To test using WireMock, change the URL to: http://locahost:9090/postcodes/so239ta.

This is achieved by defining mappings where enough of an http request is defined (in a .json file) to make it unique. For example, the following definition, would return Hello world! With a status of 200, for a GET request with URL http://localhost:9090/some/thing

This single-file definition works well when the response is short, but for more typical responses, it is better to define the response body in a separate file, which the mapping file points to.

Location of the Mapping Files

When WireMock starts for the first time, it creates two sub-folders in the folder defined as root-dir in the launch command, above.

Mapping files, such as the one above, are placed in the mappings folder. Response definition files are placed in __files.

To mock the Postcodes API call, the mapping file is:

The response file is:

Start WireMock

From a command window, or a .bat file, run:

java -jar wiremock-standalone-2.4.1.jar –root-dir e://data/WireMock –bind-address localhost –port 9090

Modify the Postman call used earlier, which now calls the mocked service

You can see the mocked header

One advantage of separating the response body into separate files, is that the response can be re-used for situations where the same response can be returned for different requests. For example, the real Postcodes service allows you to keep the space in the postcode format: ‘XXNN NXX’. Create a second mapping file with a space (%20) in the URL, that points to the same response file:

Returns the same response

Testing Various Conditions

The above examples showed Wiremock being used for calls that worked (i.e HTTP 200). In order to test for non-200 status codes, you define different key values in the mapping file. For example, to test for a ‘postcode not found’ condition, you would probably define a post code that couldn’t exist (but you don’t have to).

If you want to test for HTTP 500, you simply choose a postcode value and match it to a response file that contains the response for a 500. The aim being to test for all of the conditions that you want to handle.


I hope you

have found something of use and interest in the series, and how I have shared my experiences of using these tools, and will investigate and use them yourself.

Leave a Comment