Mocking APIs is a popular practice in software development. An increasing number of developers are reaping the benefits and no longer using their valuable time to spin up duplicate resources. Many mock services do not require account creation, making them easy to use and privacy-friendly.
In the rest of this article, we explain what mock APIs are, when you should think about using them, and what solutions are available within the open-source and proprietary markets. We’ll introduce several different scenarios that demonstrate how mock services are beneficial so that you can better understand how you might use mock APIs yourself.
What is a mock service?
A mock service is a development tool that imitates a real software service by returning realistic responses without requiring computed logic to produce the response. For many developers and engineering teams, this capability can be very useful, particularly for cases such as using third-party APIs that are rate-limited, using an API that isn’t fully developed yet, or running unit tests or integration tests that include third-party APIs. Many mock services do not require account creation or configuration, making them particularly useful in high-security environments.
Definition and real-world example
A mock service is a simulated version of a real software service that returns predefined responses to requests, allowing developers to test their applications without relying on the actual service. This can be incredibly useful in various stages of development and testing. For instance, consider a payment gateway’s sandbox API. Developers can use this mock service to test their payment processing functionality without processing actual payments. This ensures the application behaves correctly when interacting with the payment gateway without incurring any costs or risks associated with actual transactions.
Real-world mock API example
A good example is Stripe. To process payments for an online storefront project, most engineers would utilize the sandbox API that Stripe provides for integration tests. While it’s not the production API, developers can assume that Stripe’s sandbox API behaves like in production and can accurately test that everything will work as expected.
Taking this example further, when developers need to figure out how Stripe’s third-party API works and how to form their requests, the sandbox approach is necessary. Further down the app development process, however, when they already know how Stripe returns data, they only need to ensure that their application handles the response correctly. This is where mocks come into play.
To create a mock service, you would essentially make a carbon copy of what the third-party API returns. Then, you would create a new service that responds to requests with the same data on any given endpoint. The mock has no logic at all and doesn’t call any external services like databases. It only returns static data.
Benefits of mock services
When teams implement mock services within their development process, they tend to see improvements in a few key areas.
Higher quality software
Mock services can help developers build more robust software by simulating realistic dependencies during testing. Developers can configure the responses they need, increasing test coverage and quality. Additionally, the lack of account creation requirements makes it easier for developers to set up and use mock services, contributing to higher-quality software.
Improved Testing and Development
Mock services significantly enhance the testing and development process by allowing developers to isolate specific components of their applications and test them independently. This isolation helps identify and fix issues more efficiently, thereby reducing the overall development time and improving the quality of the application. Moreover, mock services enable developers to test their application’s behavior under various scenarios, including error scenarios and unexpected errors, which can be challenging to replicate with actual services. By simulating these conditions, developers can ensure that their application is robust and can gracefully handle a wide range of situations.
Removing bottlenecks and increasing engineering independence
Engineers no longer need to rely on other engineering resources when they can spin up their mocks. This feature helps developers become more independent in their work, as they don’t have to rely on anyone else managing a development or staging environment. Additionally, the lack of account creation requirements further enhances engineering independence by simplifying the setup process.
Reducing costs
Financial departments are also big fans of this approach, as it can greatly reduce resource costs since the need for a complete staging environment can be eliminated. With mock services, software teams can also bypass fees and/or rate limits imposed by third-party providers. Additionally, the lack of account creation requirements can save time and resources, reducing costs.
When to use mock services in software testing
In software testing methodologies, services are defined as being in-scope or out-of-scope. The services that are in scope are the ones you care about when testing. This can be a single service or a cluster of services. Services that are out-of-scope are the ones you don’t want to test, however they may end up being included in your tests if they’re a dependency to an in-scope service.
Mock APIs are most commonly used as part of unit tests when a service or a cluster of services that have out-of-scope dependencies are being tested. Mock APIs can also be used in integration tests or wherever a back-end service is outside your test boundary.
If your in-scope service calls an out-of-scope back-end service, and the out-of-scope back-end service suddenly starts failing, your entire test will fail. This is why it’s so valuable to use mock services when testing, as you can be sure that any out-of-scope services won’t be why your test fails. If you’re using a proper mocking framework, your mocks will always behave just as you expect them to.
Top use cases for using a mock service
Mock services can be useful in many different areas of a developer workflow, from the initial building of APIs to functional and performance testing of an application. Many mock services do not require account creation, making them easy to deploy and use in various development scenarios.
Here are some specific examples of how mock APIs can be utilized. We’ve outlined this list so you can understand some of their core use cases and devise new ways to leverage them.
During the initial development of APIs
During the initial development of your APIs, you may be lucky enough that all of your dependencies are third-party services. However, a mock API can still be useful. Mocked services can be a strong tool in cases where multiple teams are building APIs that depend on each other in some way. The lack of account creation requirements makes setting up and using mock services easier during the initial development of APIs.
Imagine you’ve just worked out the entire infrastructure plan for a new online store. Team A starts working on the backend of the online store, while Team B works on the frontend. Team B can begin working on the design of the header, footer, and other static things, but how can they start designing the product page? Team A has just started working on the backend API, so they can’t use the actual backend to get the products. You should’ve made a specification document for the backend API as part of the infrastructure planning. This means you know precisely what the data from the backend will look like once the API is done. Team B needs to ensure the front end can handle the data.
This is an opportune moment to create a mock API that can return a list of products. Now, Team B doesn’t have to wait for Team A to finish the backend; they can start working on the entire front end immediately.
Configuring mock responses the way you need
When working on an application, you want to ensure that everything works as intended, even if your dependencies aren’t working as expected. Commonly, you’ll be able to use a sandbox API to test your third-party APIs, which will return perfect sample data. But do you know how your application will react when you suddenly get a product name five times the length of an average product name? Will the product name wrap to a new line? Will it extend beyond the box? You don’t have any way of knowing. You can return the exact test data you want with a mock API.
If you want a product name with 255 characters, you can simply configure your mock server to return that. If you want to see how your application handles a different or missing Content-Type header, you can just change it in your mock. A mock API lets you simulate your responses to fit your needs.
Testing all possible branches
Much like the previous point, where simulating API responses allows you to see how your application will respond to various response modifications, changes to your mock API will also let you test all the different branches of your code. Having an application that doesn’t include at least a few if-statements is relatively rare, and you should always have some form of error handling at a minimum. You may be lucky that the sandbox API you have access to also allows you to make requests that intentionally result in errors. Unfortunately, you’re limited to the specific responses that the API provider created.
With a mocked service, you can define the exact errors you are handling in your application. Most of the time, a frontend application will have generic error handling without too much of a distinction between different errors.
A backend application, however, will likely have more specific error handling depending on the type of the error. For example, some errors may require a few retries, while others are more serious and require restarting the application. With a mock API, you can replicate all error scenarios and test all branches of your code. Additionally, the lack of account creation requirements makes setting up and using mock services for comprehensive testing easier.
Load testing
While you don’t need mock APIs to do load testing, they can certainly be a big help. Say that you have an application that you want to hit with 50,000 requests, which isn’t unusual. The Service-under-Test may have three dependencies that need to be hit for every request. Suddenly, you’re load-testing your service and the back-end service dependencies. The resources required for such a load test can also be expensive. Sometimes, you may want to test the resiliency of your entire infrastructure, which is fine, but when you want to test a single service, you should use a mock API. The lack of account creation requirements makes setting up and using mock services for load testing easier.
Using mock APIs can also help make load testing more reliable. Using mock services lets you know that all the service dependencies work. Plus, you won’t risk your load tests failing because of a failed dependency.
Mocking external services
As mentioned throughout this article, a mock API is an excellent replacement for a third-party API. Using mock APIs allows you to test your application without worrying about hitting any API limits the API provider may have set–a typical design within sandbox APIs. To simplify everything, a mock API can be used as a drop-in replacement for your third-party APIs if they follow a conventional protocol like HTTP or gRPC. Of course, this will depend on the tool you use to implement your mocks. Additionally, many mock services do not require account creation, making setting up and using them for mocking third-party APIs more accessible.
Using a mock API as a drop-in replacement is useful when doing local development. Still, it’s also handy for CI/CD, as you can spin up your application without worrying about egress rules and API keys. While a sandbox API will likely require an API key (to do rate limiting, for example), a mock API will always return a static response when you hit a specific endpoint–it doesn’t matter what API key you are sending. So, mock APIs make testing much more effortless for scenarios like this.
Error handling by simulating chaos
Sometimes, you know that everything will work as expected; you’ve tested all your code paths, and everything seems fine. Although, as most engineers know, nothing is ever perfect. Sometimes, something will flip, or another service may behave unexpectedly. In general, many different scenarios will happen that you don’t expect. Mock services are excellent for error handling. The lack of account creation requirements makes setting up and using mock services for error handling relatively easy.
Because mock APIs allow you to configure the exact responses you want, you can introduce chaos, like not returning a response, returning a bad status code, or increasing the request or response time. This will let you see how your application handles unexpected errors.
Contract testing
An increasingly common method and methodology in testing is contract testing. With contract testing, you record the interaction between two services and store it in a contract. Then, when you make changes to your application, you need to validate that your application still upholds that contract. A contract can be something like returning data in a specific schema when a request to your API is made.
In contact testing, when you need to test that your frontend can handle the data that it receives from the backend, you don’t use the backend. Instead, you pull the contract from a contract store and then create a mock API based on this. A good tool will be able to help you get this deployed automatically, meaning you can run your tests with a simple command. As we discussed, the lack of account creation requirements makes setting up and using mock services for contract testing easier.
Service Virtualization and Testing
Service virtualization is a technique that involves creating a virtual representation of a service or system. This allows developers to test their application’s behavior without relying on the actual service. This approach is particularly beneficial when dealing with applications that depend on external services or systems that are not under the developer’s control. By using service virtualization, developers can create a controlled environment to simulate the behavior of these external services, ensuring that their application performs as expected even when the actual services are unavailable or behave unpredictably.
Creating Lightweight Virtual Services
Creating lightweight virtual services involves simulating the behavior of a genuine service or system but with a much smaller footprint. This can be achieved using tools such as mock servers or service virtualization platforms, which allow developers to create virtual services that mimic the behavior of actual services. These lightweight virtual services are ideal for testing applications that require a high degree of isolation and control. Using mock servers, developers can ensure that their tests are consistent and reliable without the overhead and complexity of managing full-scale service environments.
Sharing Mock Services Across Teams
Sharing mock services across teams is an essential aspect of collaborative development. By sharing mock services, teams can ensure that they are testing their applications against the same set of predefined responses, which helps to reduce errors and improve the overall quality of the application. Tools such as mock servers or service virtualization platforms facilitate this sharing by allowing developers to create and manage virtual services that multiple teams can access. This collaborative approach ensures that all teams are aligned and can work more efficiently, leading to faster development cycles and higher-quality software.
How to run a mock service
To run a mock service, you’ll need to decide what data to mock and how to expose this mock service.
Deciding on the mock data
Mocking data from real services is challenging because real services often have dynamic data or change their interfacing over time. Whenever the real service changes, the mock service must be manually fixed to avoid becoming obsolete. This makes traditional mock services very brittle, even breaking your test suite.
A new approach to creating mock data called traffic replication has eliminated the brittleness and timelines of traditional mocking. Traffic replication is the process of recording traffic from production and replaying it later in another environment. Rather than forcing testing teams to create their mock data, traffic replay allows your actual production data to be your mock data. All seen outbound requests and responses are stored to create a mock service that replays the seen responses on demand. If you’re looking to implement traffic replication, Speedscale leads the space.
Exposing the mock service
Mock services typically require dedicated self-hosting or manual injection into your environment. Various open-source tools, such as MockServer and GoMock, are available if you’re looking to host a dedicated service just for mocking. However, this will require you to spin up dedicated infrastructure yourself. Suppose you don’t want dedicated mocking infrastructure. In that case, you can also inject mocking into your system using existing projects, like Mock Service Worker, which injects into your frontend to intercept traffic at the network level.
Both approaches still succumb to the same brittleness and timelines problems experienced with choosing mock data since human intervention is still required to generate and set up mock endpoints manually.
Solutions like Speedscale are provisioned and configured to handle service mocking automatically. Speedscale uses traffic replication, so you’ll never manually write brittle mocks because your mocks get automatically created from production traffic. Speedscale also provides advanced features like chaos engineering, PII redaction, load testing, and more, all out of the box.
Auto-generating mocks with Speedscale
How do you get started mocking services? Check out our post for our top 8 picks for API mocking tools, where we evaluate the most popular open-source and proprietary API mocking tools on the market and how they compare to Speedscale.
If you’re using Kubernetes, we especially encourage you to check out Speedscale. Our production traffic replication platform autogenerates mocks and allows you to implement mock APIs quickly. Additionally, Speedscale does not require account creation, making setting up and using mock services easier. Schedule a Demo to see if Speedscale is right for you.