Provider Example (JavaScript)

Published date: April 15, 2024, Version: 1.0

Overview

This Tutorial documents and illustrates the solution for Provider End Implementation that was performed against the ‘GetProducts’ API in CDS. This can serve as a reference for how Provider tests and workflows can be done.

Quick Links

Feature toggle Code Maintainability Deployment Automation Monitoring and Observability

Code Files To Maintain:

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
Once code implementation is complete, PROVIDER should execute the code to generate the test result.
Once results are generated, PROVIDER should use ‘publish’ command and push the verification results and OAS document to Pactflow.

Dredd Configuration File:

This file helps you maintain the configurations to control your test execution. Please refer to below code to gain better understanding on various fields that could be incorporated in this file.

Dredd Hooks File:

This file helps you maintain the code which helps in setting up and tearing down some pre and post-test conditions.

What is Dredd: It is a language-agnostic command-line tool for validating API description document against backend implementation of the API. Dredd reads your API description and step by step validates whether your API implementation replies with responses as they are described in the documentation.

How Dredd Performs Validations: Dredd reads your API description and step by step validates whether your API implementation replies with responses as they are described in the documentation. For this validate, Dredd uses Gavel library

2. What all is validated by Gavel Internally:

              a. Response / Status Code

                b. Request & Response Headers

                c. Request & Response Body Schema

Limitations With Gavel Assertion:
Gavel does not catch the DATA TYPE MISMATCH in the API response, it only validates whether all the fields specified in the examples section in the OAS are returned in the API response.

What Changes Have Been Made In Dredd Library To Overcome This Issue:

In order to include Data Type validation in API response, I have made some changes in Dredd library's default code base. CHAI Assertions is another library that is used in validating the API response and this one also validated the Data Type of the fields returned in the API response.
Following classes have been modified in Dredd's default code base to incorporate the data type assertions / validations:
1. configUtils.js
2. TransactionRunner.js
3. MarkdownReporter.js
4. hooksLogs.js
5. DreddHooks.js

NOTE:

Originally the library/package is named as “dredd” but it has been modified locally & re-published as 'dredd-using-gavel-and-chai-assertions'.
You could download the customized Dredd package from below URL:
npm: dredd-using-gavel-and-chai-assertions
Please go through the official documentation of the following to check more on this:
1. Dredd: Quickstart — Dredd latest documentation
2. Gavel Library For Assertions: https://relishapp.com/apiary/gavel/docs
Please ensure to test out your API/Service against the OAS spec in real time using this customized library to ensure that it works as expected, there are no errors in it, and it is doing the job it is intended to do. Also, please feel to make any changes in it from your end to make it work as per your expectations.

Test Execution:

“package.json” file consists of the following commands:

“providerTest“: Executes the PROVIDER tests (Dredd config and hooks files) to validate the API in real-time against the OAS document.
“publish:provider:GetProductApi“: Publishes the PROVIDER results + OAS document to Pactflow.

Pactflow Verification Process:

Once both CONSUMER and PROVIDER have pushed their contracts to Pactflow, the validation process gets automatically triggered and results are generated accordingly.
Pactflow Results:
1. Unverified: When CONSUMER has yet not been verified, we get this one when PROVIDER has not pushed his part to Pactflow.
2. Success: When CONSUMER and PROVIDER both adhere to the OAS document.
3. Failed: When either of the two parties are not adhering to the single source of truth (OAS doc).

Details View of Contract Comparison: It shows the following tabs.

a. Contract Comparison: Tells whether contract is passing or failing the validation.

b. Consumer Contract: Tells whether CONSUMER end is passing or failing the validation.

c. Provider Contract: Tells whether PROVIDER end is passing or failing the validation.

Pactflow Comparison Matrix: Pactflow matrix maintains the validation history of the comparisons made between various versions of CONSUMER against various version of PROVIDER.