...

Pact is already used for interactions between https://github.com/openedx/edx-val and 2U’s proprietary video encoding manger; the public side is implemented in https://github.com/openedx/edx-val/blob/master/.github/workflows/ci.yml, and 2U pays for the PactFlow service as the contract broker which keeps all the code related to the contracts properly synchronized.

...

Pact was discovered by some edX staff by late 2017 and advocated as a potential solution for recurring pain around the performance, efficacy, and maintenance of end to end tests. But it wasn’t until 2021 that a pilot project to use it was actually approved. The implementing team at Arbisoft presented the results, but there wasn’t a strong followup (the learning materials available at the time didn’t lend themselves to quickly grasping when and how to use the tool in new services). In 2023, it is again being promoted as a potential solution for some common types of deployment incidents, especially as microservices and micro frontends proliferate in the Open edX system.

Creating Pact Consumer Tests

The first step in creating a Pact between a consumer and provider is generating a contract on the consumer side. This contract will encompass the entirety of expected requests and return values between the two services. This includes paths of API endpoints, HTTP status codes, and response bodies of these API calls. A contract can contain as many interactions as deemed fit to ensure validity between the consumer and provider. The Pact Foundation package will produce this contract, and thus we’re given flexibility in the testing framework we want to implement in our codebase. These contracts will fed into a general Pact stub server ran on a Docker container with a specialized image, detailed here. These contracts will be of further use to us when we integrate tests into our provider service.

Next Steps

We need to find and/or create good resources for developers to quickly learn how and when to use Pact. Usage will remain limited until we can get many developers to view contract tests as just another standard quality assurance tool to use alongside other kinds of automated tests when appropriate. Potential resources will be collected in a child page for review and curation.

...