Generate Mock APIs
Last updated
Was this helpful?
Last updated
Was this helpful?
Tests that make requests to upstream APIs can suffer from intermittent failures due to updates or downtime. Because upstream APIs can also call other APIs, depending on live services tend to make tests slow. Having flaky and slow tests means more time is spent debugging and less time spent on core features.
Below we highlight two types of mock API's and provide examples for each:
Language specific libraries such as and
External mock servers such as and
In the following two sections, we list challenges with creating and maintaining API mocks. We then summarize how the challengs can be solved by using existing solutions.
Creating the initial API mocks is an upfront time cost by Software Engineers and QA Engineers.
The following lists challenges with creating API mocks and highlights existing solutions:
Maintenance is a variable time cost by Software Engineers and QA Engineers. Every time the request or response contract changes, mocks have to be modified. This becomes a time-consuming process as more and more API endpoints are added. Time spent maintaining scales exponentially with the number of request variations.
The following lists challenges with maintaining mocks and highlights existing solutions:
Determining which requests and responses need updating
Work with service maintainers
Audit change logs of upstream API changes
Wait for tests that depend on an out-of-date response to fail
Updating mock request variations with up-to-date parameters and/or responses
Manually copy/paste or edit the request and/or response
In order to generate mock APIs, we want to ensure that:
Request responses can be recorded instead of hard-coding
Precisely matching requests with responses
In order to maintain mock APIs, we want to ensure that:
Request responses can be refreshed without having to manually update each one
Stoobly makes creating realistic mocks fast and accessing them precise.
In comparison, to generate HTTP request mocks without recording:
Use a client driver (e.g. curl, browser) to send a HTTP request
Copy and paste the HTTP response into a mock tool or library
Repeat for different request variations and/or endpoints
We can see that this process quickly becomes difficult to scale. As either the number of HTTP request variations increase or as new endpoints are added, we have to keep manually adding responses to our mocks.
With recording, the process looks like:
Configure a client driver (e.g. curl, browser) to proxy requests to Stoobly
Send a HTTP request and let Stoobly record it for you
Repeat for as many HTTP requests as you want
e.g. rewriting any part of the request to filter sensitive data
Stoobly comes out of the box with comprehensive request and response matching that should cover most use-cases without explicitly stating the match requirements. By default, Stoobly matches a HTTP request by looking for exact match of path, query params and body. If needed, match rules can be configured to relax or tighten matching requirements.
In comparison, to configure how HTTP requests are matched when mocking manually:
Specify a exact path to match or use regex for pattern matching
Repeat for every HTTP request that the mock API needs to support
An additional difficultly to highlight here is that matching bodies is often not possible. This is because the body would first have to be pared based on the specified content type.
With Stoobly mocking, the process looks like:
Requests will be matched without additional configuration
e.g. Matching based on specific query params and/or ignore headers
Stoobly helps minimize the impact of having to maintain mocks.
Determining which requests and responses need updating
Shared maintenance, updates by producer can immediately be accessed by consumers
Updating mock request variations with up-to-date parameters and/or responses
Support replaying requests and recording the responses
Group a sequence of requests into scenarios and batch replay and record
The process to update a HTTP response mock manually will look similar to:
Determine which mocks need updating
Use a client driver to resend a HTTP request
Copy and paste the updated response
Repeat for other mocks that need updating
While to above flow may not mirror exactly how mocks are always updated (sometimes we directly modify the mock), it serves to illustrates the difficutly in:
Understanding which mocks need updating
Understanding what a new correct version of the mock looks like
This problem gets even worse when we want to update a sequence of requests that have a relationship with each other (e.g. creating, reading, and deleting a resource are connected by the resource ID).
The process can look similar to:
Determine which requests or scenarios need updating
Replay and record the requests or scenarios
Stoobly lets you easily by recording HTTP traffic. To record traffic, Stoobly acts as a proxy between a client and server and intercepts traffic that passes through.
(Optional) Stoobly enables and .
(Optional) Stoobly enables . Matching against query params, body or headers can be either relaxed or tightened.
We empower you with the ability to and either overwrite the existing request response or alternatively, create a new version of the request. The following lists challenges with maintaining mocks and highlights manually: