...
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.
...
Summary: https://2023.pythonwebconf.com/presentations/why-you-should-contract-test-your-microservices
Slides: https://github.com/DawoudSheraz/conference-talks/tree/master/python-web-conf-23
Recording: https://drivewww.googleyoutube.com/file/d/1XE0JGH_q26Mh-HhrMPKPv5IZFkEI9lVJ/view?ts=64703dcb (may only be visible to 2U folk, public recording should be available in June)watch?v=nA2Pv00dPgE
History in Open edX
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 be 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.
Creating Pact Provider Verification Tests
After setting up our consumer tests, we need a way to verify our contract against our provider service. Fortunately, Pact has an in-built Verifier than can match up a instantiated Provider state with what our contract expects of it. We simulate our Consumer request to the Provider, and we alter our Provider state in regards to what should be returned when a certain endpoint is hit. It is important that we discard and clean up all of our testing states after our Pact Verification has concluded. This slideshow gives a visual example of the verification system that is used on Pact consumer-generated contracts.
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.