Types of Contracts Testing – Consumer Driven, Provider Driven and Contract Driven

The terms Contract Testing and “Consumer Driven Contract Testing” are often used interchangeably thereby making it seem like they are one and the same. However that is hardly the case. CDCT was largely popularised by Pact and it is a clever technique to learn. However there other types of contract also.

1. Consumer / API Client
   • Creates a mock server to emulate the Provider / API / Service to make progress independent of the API / Provider
   • Generates API Contract based on this mock server – This is why it is known as Consumer Driven Contract
   • This Contract is shared with the Provider through a co-ordination / collaboration mechanism such as broker
2. Provider / API
   • Runs the API Contract generated by the Consumer as a test against itself to verify if it (Provider) is behaving as per the Consumer’s expectation
   • It then publishes the verification result to the Consumers through the broker or other similar mechanisms
3. Based on contract published by each consumer and corresponding verification status shared by the providers we can then determine if these consumers and providers can be deployed together

Here is a visual explanation of the same.

Pros

1. Suitable for client first / client centric development style such as Backend For Frontend (BFF) where we start by building the client and only then build the provider
2. In scenarios where many consumers are talking to a single provider, each consumer can generate the contract from its point of view
3. Provides strong guarantees in identifying compatibility issues

Cons

1. Sequential Style of Development – As you may have noticed, since the contracts are generated by the consumer, providers have to wait for consumers
2. Consumer Bias in API Design – API design may become consumer centric since we are not necessarily starting with the API design or provider architecture in mind
3. Learning curve and barrier for entry – IMHO Consumer Driven Contract Testing promotes good practices such as starting with the tests on consumer applications (especially the code first consumer driven contract testing approach of Pact), however this can also be a barrier for entry on some teams

Provider Driven Contracts

Spring Cloud Contract in “producer contract testing approach” leverages this technique (Spring Cloud Contract also supports Consumer Driven Contract Testing). Here is a brief summary of how this works.

1. Provider / API
   • Creates the Contract and runs it as a test against itself to verify that it has satisfied the same
   • In the process it generates stubs that can emulate it (Provider)
   • These stubs are shared with Consumers through a mechanism such as artifact manager, broker, source control, etc.
2. Consumer / API Client
   • Runs the stub servers shared by the provider to emulate the provider
   • Builds the client application with these stubs as reference
3. Based on stubs published by providers and consumers being able to work with these stubs, we can determine if these consumers and providers can be deployed together

Pros

1. Suitable for provider first / api centric development style such as public facing APIs, where we need not collaborate with the API consumers to design the API

Cons

1. Sequential Style of Development – Since the contracts are created by the provider and the stubs are only generated as part of the providers verifying themselves against the contracts, consumers have to wait
2. Provider Bias in API Design – API design is provider centric, Example: provider may under or oversupply information requiring consumers to do additional processing

Bi-Directional Contract Testing (BDCT)

Pactflow supports this approach where both consumers and providers have their own contracts. Please refer to the detailed explanation, use cases and tradeoffs.

Pros

1. Suitable for many real world use cases such as Retrofitting Contract Testing to existing projects, etc.
2. Consumer and Provider need

Cons

1. Guarantees are not as strong as Consumer Driven Contract Testing

Contract Driven Development (CDD)

Contract Driven Development leverages API Specifications such as OpenAPI as Executable Contracts. Below is a visual explanation of how Specmatic embodies CDD.

Here is a quick explainer video.

Pros

1. OpenAPI is your API Contract which means you only have a single source of truth for both API Specification and Contract, unlike other approaches
2. Allows parallel development of consumer and provider
3. Suitable for all styles of development such as Consumer First, Provider First and API First

Cons

1. Discourages code generation – While this can be argued as a positive point, on teams that are accustomed to generating API Specifications and / or provider and consumer code from the API Specifications, authoring OpenAPI by hand can be a teething problem

Detailed comparisons between Contract Driven Development, CDCT, Provider Driven Contracts and BDCT

1. Specmatic (CDD) vs Pact (CDCT) and Pactflow (BDCT)
2. Specmatic (CDD) vs Spring Cloud Contract (Consumer Driven Contracts and Provider Driven Contracts)