Mock API for Microservices

Use mock APIs to cut the dependencies between your microservices. Learn how mock API tools can help you run, test and develop your microservice landscape.

Designing Microservices Using Mock APIs

The single most important factor when architecting microservices in the API contract that defines how to interact with your services. These are usually defined by an architect or senior developer who documents the endpoints, the response- and request structure. In theory, this works well, but when actually starting to implement the API contract you might notice that it needs to be changed. It could be because of certain limitations or simply that you need to expose more data to make your product function according to the business requirements.

Using a tool like Mocki, you can instead create a mock version of your microservice before you start implementing it. This way any future consumers of the API (such as your frontend team) can try it out and give you feedback before you spend any precious development time on implementing the specification. This way of working is very in line with the famous fail fast philosophy that is very popular in software development culture today.

Solving Microservice Testing Challenges Using Mock APIs

Why is microservice testing so hard? Just start the service, run the tests and stop the service again? That can be the case with well built monolithic applications. However, splitting that simple-but-huge monolith into one, two, three or maybe a hundred microservices that talk to each other makes things more complicated. Service A might require Service B to function properly, and Service B in turn talks to Service C. Running and preparing these interlinked services for different testing scenarios can be a hassle for many different reasons. In this article we will walk you through how a mock API tool like Mocki can help you test your microservice fleet at scale.

Test Independently Using Mock APIs

Instead of running the real versions of your services, mock APIs can be used. Running a light weight mock instead of the full fledged microservice can have positive impact on performance, complexity, cost, and it can even make it easier to test edge cases in your microservice.

Isolate Testing Scope

To test microservices independently, we want to keep the testing scope as small as possible. In the case above, we are running real versions of Service B and Service C during our testing. This make our scope of testing larger since it relies on the interlinked services functioning as expected. In a microservice world, each service will have its own environments. This means there might not even be a guarantee that a service is up and functioning as expected at all times.

To keep the testing scope smaller we can use mocks instead that act as stunt doubles for the real microservices. The mocks can be configured to reply as required by the test cases run and they can be run locally or in the cloud. Each service under test can define their own mocks so that you are not even dependent on a single mock for testing all of your microservices. The ownership of the mock and the configuration is in the service under test only.

Test Edge Cases Easily

When the service under tests owns the test data for interlinked services, you no longer need to request test data from other development teams to get the data that you need. Simply configure the data that the service under test needs using Mockis web interface or a configuration file in your repository and you are good to go. You can also chooose to randomize responses, generate realistic test data and simulate errors.

Case Study

If you are in a situation where you realize that you need to utilize a mock API tool for your testing workflow, we have a real world use case to give you some inspiration on how to solve your microservice testing challenges. Head on over to our article on Microservice Testing Using Mock APIs.

Save Costs

Microservices are best run in the cloud, and in the cloud you pay for each seconds that your infrastructure is running and being used. To avoid deploying more environments for testing purposes, use a mock API instead to cut the infrastructure costs that would be incurred by a real service. Using Mocki, you only pay for the requests to your mock API, the hosting and configuration comes for free. If you are running your mocks locally using our Open Source CLI tool, it is of course 100% free.

Reduce Complexity

Running, managing and deploying a large fleet of microservices is hard on its own. To avoid creating and maintaining a multitude of test environments for each microservice you can instead switching some of them for mock APIs instead. This will lower the operations effort needed to keep your microservice landscape afloat.

Increase Performance

What was that? An airplane passing by? Ah, it’s just your colleagues computer fans gasping for air when running 20 Docker containers with all your microservices. Mocks created using Mocki are lightweight and can be run both locally and in the cloud. This will save both your ears and your colleagues fans some wear and tear.

To run your microservice mock locally install the Mocki CLI tool, pull your configuration file and run mocki run --path config.yml and it will spin right up. If you need to modify the configuration file, for example to get some better data, it can be done at run time.

Get Started using a Mock API Tool Today

To get started with creating mock APIs for your microservices, head on over to our documentation to get started with Mocki. If you have any questions or want to connect with our team of microservice testing experts chat with us using the chat widget here on the site.

Good luck!