Design Patterns for Microservice Architecture – Consumer Driven Contract

In Microservice Architecture, there are many Microservices often developed by separate teams. These microservices work together to fulfill a business requirement (e.g., customer request) and communicate with each other Synchronously or Asynchronously. Integration testing of a Consumer Microservice is challenging. Usually, TestDouble is used in such scenarios for a faster and cheaper test run. But TestDouble often does not represent the real Provider Microservice. Also, if the Provider Microservice changes its API or Message, then TestDouble fails to acknowledge that. The other option is to make end-to-end testing. While end-to-end testing is mandatory before production, it is brittle, slow, expensive, and is no replacement for Integration testing (Test Pyramid).

Consumer-Driven contract testing can help us in this regard. Here, the Consumer Microservice owner team write a test suite containing its Request and expected Response (for Synchronous communication) or expected messages (for Asynchronous communication) for a particular Provider Microservice. These test suites are called explicit Contracts. For a Provider Microservice, all the Contract test suites of its Consumers are added in its automated test. When the automated test for a particular Provider Microservice is performed, it runs its own tests and the Contracts and verifies the Contract. In such a way, the contract test can help maintain the integrity of the Microservice Communication in an automated way.

Pros

• If the Provider changes the API or Message unexpectedly, it is found autonomously in a short time.
• Less surprise and more robustness, especially an enterprise application containing lots of Microservices.
• Improved team autonomy.

Cons

• Need extra work to develop and integrate Contract tests in Provider Microservice as they may use completely different test tools.
• If the Contract test does not match real Service consumption, it may lead to production failure.

When to use Consumer-Driven Contract Testing

• In large-scale enterprise business applications, where typically, different teams develop different services.

When not to use Consumer-Driven Contract Testing

• Relative simpler, smaller applications where one team develops all the Microservices.
• If the Provider Microservices are relatively stable and not under active development.

Enabling Technology

Pact, Postman, Spring Cloud Contract