Consumer Driven Contract

1. Testing interactions between microservices can be achieved using Consumer Driven Contracts to define the interactions up front. 
2. Consumer Driven Contracts can be used to validate what you’re building. CDC enables you to build what a consumer needs, not what you think they need. 
3. The Pact Framework is an Implementation of Consumer Driven Contracts. These are simple JSON files that define expected request and response structure between two microservices.

A contract between a consuming service and a providing service, stating what the consumer wants from a providing service, in a defined format.

Benefit of CDC

First; they enable services to be deployed independently. No longer do you need to have a QA environment with all of your services running in one go to test that your application works. You won’t need to do long, brittle, and expensive flow tests to ensure that your services can start up and communicate.

Another key benefit is that contracts can be generated independently of a service. Imagine you need a new endpoint for a providing service. You know what it should look like, and the exact data the new consumer will require.

The generated CDC is then given to the provider’s team for them to implement. You can then rest easy in the knowledge that, as long as the providing team follows the CDC, everything should work. This approach works very well with distributed teams. The CDC can be created, and both the consuming team and providing team can work on the code at the same time while being the entire world apart.  

Drawback

There are a number of things CDC do not cover. To start with, they are not a test of business logic. That should be covered by your service’s unit tests.