Consumer Driven Contract Testing For Microservices

Monolithic Architecture is a delicate balancing act, one that rests on understanding how any one change will affect the entire system.

This new trend is called Microservices Architecture. Instead of creating a single large application, the idea is to subdivide the single application into a set of different interconnected applications which will make it into a distributed one.


A Monitoring Tool developed by us which can primarily track Business Transactions that revolve around IBM Middlewares as well as system-metrics of respective Middlewares.

MonitorPro has a strict adherence to Microservices Architecture containing twelve Microservices.


Testing MonitorPro was quite tough because it’s written in different languages. The major issue comes to test these Distributed and Loosely-Coupled Microservices.

Integrated Tests are

  • Easy To Break

  • Hard To Fix

  • Scales Combinatorially

  • Lots of Setup

  • Extra Infrastructure

Let’s suppose three (03) classes each having four (04) code paths so, how many test cases

Ans. 4*4*4= 64 Test Cases.

Pact Comes To The Rescue

With the concept of Consumer-Driven Contract Testing, a contract is an accumulation of agreements between an API Provider and a client contracts that describes the interactions that can take place between them.

Pact: is a testing Framework that helps you write contracts and guarantees those contracts are satisfied.


For our use case we wrote test cases on the following versions of Pact written in these languages:- (no language examples)

How Does Pact Work?

The expectations are set up on a mock service provider the tests for the provider facing code in the consumer project.

When the tests are executed, the mock service returns the anticipated responses. The requests, and their expected responses, are then written to a “pact” file.

The calls/requests in the (pact file) are thereafter rerun against the provider, and the real responses are examined to confirm they match the expected responses.

The above image shows the complete working of Pact.

Step1:- Setting expectations on Mock Server Provider

We have to do an API call with any HTTP Client Library and we are all set.

We get the following JSON File generated:-

Step 2:- Pact Files Generated and Publishing to Pact Broker

Once we have got the Pact Files which is in JSON format, it needs to be published to Pact Broker or any code repository or may be in your local system from where it can be fetched and replayed against Providers.

So there are various ways you can choose what best fits for your Project and follow accordingly.

For MonitorPro we had a dedicated Pact Broker which can be installed using docker-compose file.

Now, we have to publish the pact files to this Pact Broker which was done using Pact-Maven Plugin. Add this in pom.xml on Consumer side.

Step 3:- Verifying Pacts on Provider Side

That’s it if you are still following means you are good learner. In this last step our verification will happen which will convey that we are all good for production.

Pact Allows You To

  • Reduce Your Defect Turn Around Time.
  • Decrease the number of bugs/issues that are committed into codebase - Immediate Feedback on potential integration breakages.
  • Allow you to modify components with Agility.
  • Have Confidence that all services in your system will work together.
  • Last of all, throw away your Slow Integration Test Cases.

Leave a Reply