Never mock an API again

Why we use unmock for our full stack

Let’s face it, mocking sucks. Every programming language and platform has different tools to help you mock API calls, but all of them share some common fragilities:

• No clean way to verify if the mocks are correct representations of the API.
• No way to avoid reverse engineering the API you’re mocking.
• No way to quickly mock internal APIs.
• No way to monitor in production if the mocks from your tests resemble the data that you’re getting back in the wild.

As a result, teams lose tons of time and energy writing mocks for their unit and integration tests, which leads to buggy tests, less test coverage, and ultimately a less reliable production environment.

unmock

Enter unmock. Unmock is great because it basically takes care of all of this stuff for you. There is a good YouTube overview of the service (currently in closed beta), but I thought I’d walk you through how unmock speeds our team up at Meeshkan.

The first important thing to know about unmock is that the amount of test code you write reduces drastically because you are not rolling your own mocks. In Meeshkan, we basically deleted all of our mocking code, including the logic that tied it together, and used unmock as a drop in replacement for our API calls. Tweaking the mocked responses is really intuitive, and as a result, we’ve been able to quickly write corner-case tests for all sorts of bad API calls — unexpected nulls, empty strings, etc. We’ve also spotted several incorrect assumptions about the APIs we’re using, which is a real life saver when you’re trying to build a product fast.

One feature we particularly appreciate is the way unmock deals with API calls in the same test. Basically, by clicking on “Parent” on app.unmock.io, you can go backwards in time over your mocks to see really quickly the data that is coming into your tests. Of course, you can modify all of this in a jiffy to tell the story you want to tell through your tests.

While unmock offers a save feature to download mocks locally, we actually find that this is the least useful feature of the product. At first, we were checking our mocks into version control, but we quickly realized that it is far better to have the mocks live on unmock for a variety of reasons. The main one is that you don’t have to worry about which mocks are made locally and which ones are pulled from unmock as you add more and more calls to your tests — you have a single source of mocks. Also, for graphql schemas, unmock will automatically update the schema as it is published, which avoids freezing stale mocks. Another killer feature is unmock’s production monitoring: if you get mocks from the unmock API, it will automatically track what data your API calls are seeing and then know, in production, if any of this data is off — missing, skewed, whatever.

Unmock has quickly moved to the center of our testing stack across multiple platforms — Android, iOS, and Web — so that we can build accurate tests fast without worrying about dreaded 401 errors and bugs that come from reverse engineering vendor code in your tests. Try to get in on the beta if you can!