API Mocks and why should we care
Tags: testing, automation, mobiletesting, api
Published: 2018-02-21 05:26:44

---
title: "API Mocks and why should we care"
published: true
tags: testing,automation,mobile-testing,api
canonical_url: 
---

![](https://cdn-images-1.medium.com/max/1024/1*66KbxEMsRw0w8I_qcTT0pg.jpeg)

Service virtualization, Fakes, Stubs, Mocks, dummies etc are all different categories of Test Doubles which on broader level return _a response for a given request in a controlled manner._

A request can be a method call, Object creation&nbsp;, database interaction or an webAPI interaction.

In below article we will be talking about API mocking and try to discuss some of **what, why, how, when** of API Mocks and also some **challenges** with them. If you are more concerned about the difference amongst all different types of Test Doubles then please head over [here](https://www.infoq.com/articles/stubbing-mocking-service-virtualization-differences) and&nbsp;[here](https://martinfowler.com/articles/mocksArentStubs.html).

Enough said lets get&nbsp;started

#### **What is&nbsp;Mocking**

Mocks is nothing but an imitation(of what?). It simulates behaviour of real API but in a more a controlled manner.

A simple mock server consist of a server, which on matching certain request returns pre-defined response and other parameters associated such as response code, headers&nbsp;etc.

#### **Why API&nbsp;Mocking**

Getting quick and consistent feedback for a test are some of the key principles of continuous integration and API Mocks really help in facilitating this.

_Quick feedback_ is very obvious, but lets understand.

Quicker the feedback of testing(either manual /automation) earlier bugs are caught and fixed. Have you been in a situation where a single test scenario take 15 min to complete with flaky payment service (roughly around 12 API calls), If yes embrace API&nbsp;Mocks.

What do we mean by _“consistent/deterministic results”_?.

Consider an airline booking application where we have to check whether user is able&nbsp;to

- Search for flight from&nbsp;PUN-DEL
- Select Seats for the passenger
- Add trip extras like “in-flight wifi”&nbsp;etc
- Complete Purchase

Over here search results, availability of seats and Trip Extras will vary depending on the current state of the flight, hence non deterministic tests.

But if we have mocked API responses for seat availability, then seat 25A will always be available.

Other benefits of API mocks&nbsp;are

- If we are doing visual comparison of screen, then data painted on each screen also needs to be consistent in order for visuals comparison to&nbsp;work.
- Validating manually scenarios when test environment is not available by pointing to&nbsp;Mocks.
- Validating issues(prod/new issue) with different version of apps by pointing to same mock environment.
- If backend and UI development are happening in parallel then UI needs a contract/dummy response to work&nbsp;with.

#### **What to&nbsp;Mock?**

As this article is pretty much about mocking backend, so yes backend should be mocked, but what if your team is owning some bit of backend(1 or 2 service) and&nbsp;UI.

Question to ask&nbsp;is

> Should we mock backend APIs that we own or all the backend APIs to UI should be&nbsp;mocked.

![](https://cdn-images-1.medium.com/max/1024/1*Mnngq59LoQMeacfmPhIleg.png)<figcaption>Backend Mocked</figcaption>

If you are looking for a straight answers then “We should mock all the backend APIs of components which are owned by Team”.&nbsp;agree?

Let say team somehow agreed to approach where everything backend to UI will be mocked. Refer&nbsp;below

![](https://cdn-images-1.medium.com/max/1024/1*Z24cwTHzTA5BC_80RYvdQg.png)<figcaption>UI Backend Mocked</figcaption>

One fine day if SHIM layer owned by team is changed without making changes to UI then your UI test case will **NOT** raise any flags as they are always working with the mocked response and test will be returning false positives.

False positive is the last thing which you want in environment where confidence in automation test case is really&nbsp;crucial.

_Food for thought_&nbsp;: Is this problem with every API mocking(Let me know your thoughts in comments section, if yes how we can keep a&nbsp;check?)

#### How to API&nbsp;mock

First thing First&nbsp;: For mocking API, we need configuration in our app which can selectively point to mocks environment or live services based on the switch. It can be a javascript function which can change host & port or setting page in test builds for mobile app where one can select environment.

For writing mocks there are many open source tools available, personally I never felt the need to go for the paid solution for mocks or service virtualization.

Some of the popular open source solutions are [wiremock](http://wiremock.org/), [MounteBank](http://www.mbtest.org). There is good documentation and “Getting Started” help available on respective tools website, but just to give glimpse how easy is to write mock for GET request, here is a&nbsp;snippet.

A simple mock GET request for “greet” in wiremock looks as&nbsp;follows

```
public class Test {

public static void main(String[] args){
        stubFor(get(urlEqualTo("/greet"))
                .willReturn(aResponse().withBody("Hello World")));
    }
}
```

If responses are big then storing them in file and returning file content is something to consider.

Also mocked response can be templatized to include date sensitive responses like greet users with “todays&nbsp;date”.

```
public static void main(String[] args){
    stubFor(get(urlEqualTo("/greet"))
            .willReturn(aResponse().withBody("Hello World, today is:"+ DateTime.now())));
}
```

#### **When to API&nbsp;mocks**

It again depends upon the project, if we have agreed on why part of it, based on the automation need, it should be early in the project also if any of the backend service is flaky or slow then those should be&nbsp;mocked.

#### **Challenges**

As we have seen above API mocks really comes handy for UI automation and other manual scenarios but there are some challenges associated with&nbsp;it.

**States in&nbsp;Mocks**

Mocking gets more complex if we have states in our app for example&nbsp;: /greeting api will return “Hello World” and then on subsequent /greeting we need to return “Hello Universe”.

> Great powers comes with great responsibilities

Also, this prevents parallelization of test cases as one fine day states will interfere and test will fail and debugging will take&nbsp;ages.

**Stale mocks**

As we discussed in what to mocks section, there are chances mocks will become stale and there is no clear way to know when they have become stale(unless clubbed with Contract&nbsp;tests) **.**

**Templates**

![](https://cdn-images-1.medium.com/max/225/1*-bQMHPTZfCp-Pm4n9ilskA.jpeg)

Templatization issues for Date time needs to be sorted very carefully, if UI tests and mocks are running in different timezones.

**Broken Request**

Consider a request with all mandatory objects

```
{
  "action": "greet",
  "name": "kapil",
  "date": "2018-02-01"
}
```

In order to make mocks simple, quite many times mocks mapping for the above request would be something like

```
stubFor(post(urlEqualTo("/greet"))
        .withRequestBody(containing("greet"))
        .withRequestBody(containing("kapil"))
        .willReturn(aResponse().withBody("Hello Kapil!")));
```

Now consider a scenario where there is a bug and mandatory “date” object is not coming in request, our UI automation test case will always pass again giving false positives.

**Effort for mock&nbsp;updates**

Last but not the least, effort required to update mocks(or automated way to do that) when backend changes is something to consider upfront and this is coming from an experience of working in project that has ~3000 mock responses.

And thats pretty much it, I hope this article has given insights in API mocking. Will be discussing about some challenges in follow up post. Do let me know your feedback in comment section, and if you like the article do&nbsp;share.