Using Mock Servers in Microservice Development — Oversimplified

Consider a simple microservice architecture. Microservice A produces a message to a Kafka topic. Microservice B is a consumer for the same topic and reads the message. Microservice B also needs to make a synchronous HTTP REST call to Microservice C to fetch additional information, compute data, and then save it to the database.

Team A manages Microservice A, Team B manages Microservice B, and …you get the idea.

A developer named Saurav 😊 in Team B has been assigned the development of a new feature in Microservice B.

After completing local development and unit testing, Saurav now publishes his changes to GitHub and gets his changes deployed to the development environment for testing. However, he finds out that Team A and Team C don’t have a development environment! We all have faced this problem.

What can Saurav do?

Skip development testing!

He could do away with the development testing and move directly to the release environment and hand it to the QA for validation.

Well, you know how untrusting the QAs are 🤨. So what other option does Saurav have?

Wait for the other teams to set up their development environment

He could reach out to Team A and Team B to set up the development environment and share the details for integration.

Saurav definitely doesn’t want to end up like the meme above.

Mock with Microcks

Microservice A being a Kafka Producer in event driven architecture should have a AsyncAPI specification to describe and document message-driven APIs in a machine-readable format. Similarly Microservice C, a REST based service should have OpenAPI Specification describing standard, language-agnostic interface to HTTP APIs.

We can leverage these specification documents to spin up a mock instances of Microservice A and Microservice B.

Mocking Kafka Producer — https://microcks.io/blog/apache-kafka-mocking-testing/

Mocking HTTP Rest API — https://microcks.io/documentation/using/advanced/templates/

Happy Mocking!