Bi-Directional Contract Testing

In bi-directional contract testing, the “Pactflow” acts as the mediator layer between the consumer and the provider. It is the single source of truth and determines the validity of the API. This document, referred to as the OAS - Open API Specification (previously referred to as Swagger), is what developers need to examine and have available to help them create the coding portions of the implementation.

Consumer’s “package.json” file should consist of the following commands:

1. “consumerTest“: Executes the CONSUMER tests to generate the Contract.
2. “publish:consumer:GetProductApi“: Publishes the CONSUMER Contract to Pactflow.
3. “can-i-deploy“: Helps to verify the compatibility of CONSUMER contract against the PROVIDER

Step 1 - Create Test To Generate Consumer Contract

Developers will have to create a test file which should include code to generate the pact file or consumer contract.

Step 2 - Publish Consumer Contract To Pactflow → Publish

Once the pact/contract file is generated, developers should run the “publish“ command. The sole purpose of this command is to publish the consumer contract file/pact file to Pactflow.

Step 3 - Local Validation → Can-I-Deploy

As a last step, developers will want to verify if their consumer pact is compatible with those of the matching providers. This will ultimately check if the API is production-ready and meets all contractual requirements.
While this step can also be performed at Pactflow, it is convenient and faster to verify locally.

Step 4 - Commit Code and Trigger CI/Pipeline

At this point, once your consumer pact has been published and verified, you can commit the code and create a PR.

Provider End Implementation

1. PROVIDER should implement the code for validating the API implementation against the OAS document which is the only source of truth in BDCT. Coding at PROVIDER end in very minimal, we only need to maintain below components:

   1. Dredd configuration file.

   2. Dredd hooks file for which helps you handle some pre / post actions.

   3. OAS documents of API.

2. Once code implementation is complete, PROVIDER should execute the test to perform validation of OAS document against the actual API implementation.

3. Once test execution has passed and execution report is generated, PROVIDER should use ‘publish’ command to push the verification results and OAS document to Pactflow.

Provider’s “package.json” file should consist of the following commands:

1. “providerTest“: Executes the PROVIDER tests to validate the API against the OAS document.

2. “publish:getProductApiProvider“: Publishes the PROVIDER Contract (text execution report + OAS document) to Pactflow.

3. “can-i-deploy“: Helps to verify the compatibility of CONSUMER contract against the PROVIDER.