Imagine a situation in which you and your team are part of a larger organization, and you are responsible for a subset of web APIs in a wider API platform. Your team has worked hard to establish some robust testing activities, and you’re about to release a new feature. The conversations before development began were productive, the exploratory testing sessions revealed lots of information, and all the automated checks are green as part of the build pipeline. You deploy the APIs only to discover that as soon as the deployment is complete, the platform falls over, and it’s returning errors—something has gone wrong.
A frantic debugging session begins, and you discover that while your team was busy working on new features, another team responsible for an API you depend on changed its endpoints, and your APIs are unable to speak to one another anymore. Although the issue can be resolved by simply updating the API code with the latest changes to our dependent APIs, the question remains, who is responsible for ensuring this type of issue doesn’t occur again? Is it your team’s responsibility to keep everyone apprised of any changes, or is the team you’re dependent on responsible for informing you of changes? This is what contract testing aims to resolve.