API mocking provides a way to test how an API is likely to perform and integrate within your system using a simulated version of an API. It can help you get stuck into testing rapidly but does have some limitations.
We’ll explore what a mock API is below and how mocking API calls can help you understand how the real version of your API is likely to perform in the same scenario.
What is API mocking?
API mocking is the creation of a simulated version of an API that mirrors the behaviour of an actual API. It’s essentially a process of creating a fake API for testing. While the API mock will lack some of the functionality of the real API, it should correspond to it sufficiently to enable you to carry out the test you need.
This basic functionality is what sets a mock API apart from other forms of simulated APIs used for testing. Stubbing, for example, refers to the use of a placeholder API that lacks any real functionality. An API mock, however, provides the functionality required to make it useful for testing purposes (but doesn’t go as far as simulation and virtualisation, which provide greater degrees of functionality than mocking).
The benefits of API mocking
Before we dive into the nitty gritty, let’s look at why you might want to create a mock API in the first place. The key benefit of doing so is that you can test it to understand the mock behaviour. This shows you how the actual API would behave in the same situation. This means you can evaluate API performance – including in complex scenarios – as well as identify bugs and iron out any glitches. All before moving on to creating your actual API product.
By testing mocks, you can move ahead quickly with your understanding of how your actual API will perform. This is why using a mock server for API testing has become such a key part of the development process.
Types of mock APIs
There are various ways that you can simulate and use mock APIs, depending on your needs. With Tyk, for example, you can use mock response middleware to return mock responses for an API endpoint without needing an upstream service.
Before you race ahead with creating your API mock, put some thought into precisely what type you need and why. This should ensure that your mock API or mock endpoint enables you to thoroughly test the performance, integration and functionality that’s important to your use case.
Public mock/dummy API
You can choose to create a mock API on a public server. If you need to test your API in relation to tooling and services that are hosted elsewhere, this is likely the most practical choice.
Local server mock API
Instead of a public mock, you could create your mock API on a local machine. This is ideal if you need offline access or require low latency during your testing.
Static vs dynamic mock data
You will need to decide whether to use static or dynamic mock data when testing your API mock. There are advantages to both.
The static mock data API model is the simplest choice. You can use static example responses for a mock API call to each endpoint. An API mocking tool can generate the dummy data for you, or you can generate them yourself. While this is a simple option, it is also limited, as your actual API will behave differently in response to different inputs. As such, static data is great for initial or limited testing, but mocking API responses with dynamic data will give you more thorough insights into your API’s behaviour.
Dynamic mock data allows you to gain realistic insights based on a wide range of different inputs. This gives you a far more comprehensive way of testing mocks’ performance and debugging them.
What’s the difference between internal and external APIs?
Mocking an internal API means matters are very much in your hands. You are in control of everything from how you create the mock to how you test it. You’ll also need to keep up with changes made during the API’s development, to ensure your API mock reflects those.
Mocking an external API can be more of a challenge. You’ll need to keep your mock API up to date with any changes but won’t necessarily have access to the API definition. Storing live results for use with your API mock can help here.
Best practices for API mocking
API mocking – when done well – can deliver insights that contribute significantly to the successful development of your actual API. By following these best practices, you can maximise your chances of getting the best out of your mock.
First, make sure that your API mock mirrors the actual one as closely as possible. That means using the same schemas, the same transport protocols and so on. This includes mocking external dependencies, so that you can test thoroughly with as close a mock to the actual API as it’s possible to achieve. If you don’t, the mock API can’t really serve its purpose in terms of comprehensive and ongoing testing.
Another best practice is to use your mock for error testing, as well as evaluating what good looks like. Throw everything you can think of at your API mock, from extended response times to invalid messages, then see how it responds. You’ll be looking for graceful error handling in your actual API, so put your mock through its paces in respect of dealing with both complexity and failure.
Common scenarios
There are numerous scenarios where API mocking really comes into its own. Let’s run through a few of these.
Mocking during development
By using a mock API, you can provide a project-specific development and testing environment for both operational teams and architects to test.
Integration and demonstration purposes
In addition to using API mocking during development, you can also use it to demonstrate to your potential customers how your API would function and integrate. This can be a handy way to showcase your product without actually deploying the real API.
Functional tests
If you need to identify bugs, see how an API handles errors and evaluate its ability to deal with complex cases, functional mock API testing is the answer.
Non-functional testing
API mocking is also useful for non-functional testing – for example, if you need to evaluate performance and response times. With an API mock, you can run through multiple scenarios rapidly, without the need to create a real backend.
External components
There will be times when you need to test whether an API plays nicely with external components. However, the actual external dependencies might not (yet) be available for you to do so. Mocking those components can provide the ability to test them until the real ones do become available.
How to implement API mocking
Ready to get started? If you want to implement API mocking, you’ll need to run through the following steps:
-
Identify your API endpoints, request methods and expected responses
-
Choose a mocking tool or library
-
Set up your mock server
-
Define the mock responses
-
Start the mock server
-
Configure your application
-
Test your application’s behaviour in various scenarios, including edge cases and errors
-
Update as required to match changes to the actual API
That’s it – by following these steps you can use your mock API to test a wide range of scenarios.
Which tool to use to mock APIs
We mentioned choosing a mocking tool or library above. One of the benefits of Tyk is that you can use our mock response middleware, but there are also plenty of other handy tools. JSON Server, Nock and WireMock are three that you might find particularly useful if you’re mocking an API for the first time.
It’s also worth pointing out that an API gateway for microservices can come in very handy if your remit involves microservice mocking and virtualisation.
Any questions? The Tyk team is always up for a chat, so if we haven’t answered all of your queries with the information above, why not reach out to us and we’ll do our best to help.
