WireMock for your Dependant-On Http Service

Recently I needed to mock an http service our appplication depends on. A developer recommended me WireMock he uses at unit level.

I target the system level. But - wow - WireMock running as standalone server gives me the same feature set thanks to it's great JSON API for configuration while running.

Here I give you an overview and some advice about how to get started mocking an HTTP service at system level.

Collection of the Mocked Data

First thing you need to know is:

• the url you call
• the data returned by those calls.

WireMock has a great record and playback feature. WireMock proxies any calls to the DOS and automatically creates files for the responses and mappings.

Example: GetWeather

We'll record responses for calling the global weather API of WebserviceX.NET.

Run

java -jar wiremock-1.58-standalone.jar --proxy-all="http://www.webservicex.net/" --record-mappings --verbose

and make a sample call to the GetWeather method, for example:

curl --header "Content-Type: text/xml;charset=UTF-8" --header "SOAPAction:her.asmxww.webserviceX.NET/GetWeather" --data @request.xml http://localhost:8080/globalweather.asmx

(request.xml containing a valid request, obviously).

This will create a file containing the response in __files and a sample mapping in mappings in your current working directory.

If you open the mapping just created you'll see something like:

{
  "request" : {
    "url" : "/globalweather.asmx",
    "method" : "POST",
    "bodyPatterns" : [ {
      "contains" : "<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:web=\"http://www.webserviceX.NET\">\n   <soapenv:Header/>\n   <soapenv:Body>\n      <web:GetWeather>\n         <!--Optional:-->\n         <web:CityName>Madrid</web:CityName>\n         <!--Optional:-->\n         <web:CountryName>Spain</web:CountryName>\n      </web:GetWeather>\n   </soapenv:Body>\n</soapenv:Envelope>"
    } ]
  },
  "response" : {
    "status" : 200,
    "bodyFileName" : "body-globalweather.asmx-8VMpb.json",
    "headers" : {
      "Cache-Control" : "private, max-age=0",
      "Content-Type" : "text/xml; charset=utf-8",
      "Content-Encoding" : "gzip",
      "Vary" : "Accept-Encoding",
      "Server" : "Microsoft-IIS/7.0",
      "X-AspNet-Version" : "4.0.30319",
      "X-Powered-By" : "ASP.NET",
      "Date" : "Sun, 26 Jun 2016 12:49:57 GMT",
      "Content-Length" : "691"
    }
  }
}

Woohoo! your first configuration for the JSON API.

You can easily check your configuration / mock data, by restarting WireMock, but this time in standalone mode

java -jar wiremock-1.58-standalone.jar

and rerunning the above curl command.

Configuration of the Mock via JSON API

While you can have a static mock configuration in the mappings and __files folders, the really cool stuff is changing the configuration during runtime / testing on the fly calling the JSON API. This way we can even control delay for performance testing.

Let's suppose you're running WireMock on it's standard port at your localhost:8080 without any previous static configuration. You then create a new configuration by posting

{
  "request" : {
    "url" : "/globalweather.asmx",
    "method" : "POST",
    "bodyPatterns" : [ {
      "contains" : "GetWeather"
    } ]
  },
  "response" : {
    "status" : 200,
    "body" : ...,
    "fixedDelayMilliseconds": 2000
  }
}

to http://localhost:8080/__admin/mappings/new causing this way the mock to respond after 2 seconds.

WireMock has many well documented features any tester could whish for.

• Stubbing the data
• Control performance related behaviour
• Setup stateful behaviour / full scenarios
• Control failures
• Verify behaviour

JSON API Cheat Sheet

Here a listing for easy reference during test development.

Method	Description	Notes
__admin/reset	Removes all stub mappings and deletes the request log.	Great for clearing mock behaviour before setting up anything
__admin/mappings	Lists all configured mappings	Helps while developing your tests
__admin/mappings/save	Saves all mappings	This way you can create a static default setup easily, and refresh it if your mappings change.
__admin/mappings/new	Creates a new mapping	Create a new mapping in setup or during a test, switching for example from success to error. By default, WireMock will use the most recently added matching stub to satisfy the request. But several mappings can even be prioritised.
__admin/mappings/reset	Removes all non-static mappings	Like full reset, but preserving your default setup.
__admin/settings __admin/socket_delay	Set the global settings for your stubbing	You can vary over delays for your performance testing.
__admin/scenarios/reset	Reset all states to START.	Again, great for resetting your test environment if you use stateful behaviour.
__admin/requests/count __admin/requests/find __admin/requests/reset	Lets you manage and check the requests log	Check requests during test development and verify DoS have been called. find with body { "urlPattern" : "/" } let's you inspect all recorded requests.

You can find the full API reference here.