Team Enablement Guidelines

Published date: April 15, 2024, Version: 1.0

Overview

Contract Testing is a practice that needs to be adopted by the entire team, not just relegated to one specific role or technical gate. Contracts are the glue that that brings the desired outcomes (earlier detection of breaking changes, more stable integrated environments, etc), and thus they must be considered by all team members across all stages of the SDLC.

Adherence to Contract Testing standards is the responsibility of the entire squad!

For CMs:

  • It is the responsibility of each CM to ensure that their leads are enforcing these standards on PRs.

For SMs:

  • It is the responsibility of each SM to ensure that the standards are in place and guidelines are followed before moving tickets ('Ready for Dev' for DoR, and ‘Closed’ for DoD)

For All Developers:

  • Whenever making any changes to an API endpoint (as a provider) or API interface (as a consumer) corresponding changes must be made in the contract tests in order for them to be able to pass As part of making any change, the version number on the pact must be incremented!
  • Any time a new API is added, it must have a corresponding contract test put in place as part of the PR. All new APIs must be covered by contract tests!

For All Leads / Reviewers:

  • Going forward, code reviews on PRs need to include checking for any new APIs that may have been added.
  • If there are any new APIs, the review must include verification that a contract test has been created for that API, and that the contract test is passing.
  • In the case of a brand new API, it will first be created by the Provider. This means that a Provider side contract test (verification of the real service adhering to the swagger spec) must be put in place and passing.
  • In the case of a new API being used by any Consumer, this means that a Consumer side contract test must be put in place and seen passing.
  • As the first consumer of any given endpoint, there should be validation that the cross check between Consumer expectations and Provider spec and results are all passing in PactFlow.

Consumer Team Specific Guidelines:

Each team that uses APIs built by other teams at CTC will need to create and document their Consumer team specific implementation guide.
This is a fully built example Consumer Implementation Guide for reference: Example Consumer Implementation Guide

Provider Team Specific Guidelines:

Each team that builds APIs used by other teams at CTC will need to create and document their Provider team specific implementation guide.
This is a fully built example Consumer Implementation Guide for reference: Example Provider Implementation Guide
It is important to ensure that the service is backward compatible when adding new endpoints or modifying existing endpoints.