A team may depend on a third-party API it cannot influence, or publish a public API without knowing every consumer. Provider-driven contract testing (PDCT), also called bi-directional contract testing, offers a contract-testing workflow for those cases. Instead of executing consumer expectations directly against provider code, it compares two published contracts: a consumer contract representing expected interactions and a provider contract representing capability, often an OpenAPI specification. section 11.0 section 11.1 section 11.4
PDCT is an alternative to consumer-driven contract testing (CDCT), not a replacement for it. It is intended to lower adoption friction by letting each side retain existing tests and tools: consumers derive contracts from test mocks or stubs, while providers publish an API specification that has already been tested. A broker performs cross-contract validation and records whether the contracts are compatible. section 11.1 section 11.1.2 section 3.7.2
A typical PDCT delivery flow is:
- Generate and publish a consumer contract from existing consumer tests, mocks, or stubs. section 3.7.2 section 11.1
- Generate and publish the provider contract, commonly an OpenAPI specification, with provider test results. section 3.7.2 section 11.1
- Compare the consumer’s expected response shape with the provider’s declared response shape in PactFlow. section 11.1
- Check the compatibility result with can-i-deploy before either side deploys changes. section 3.7.2 section 11.1
Figure 3.10 PDCT life cycle from JavaScript web application, including test mocks, through the broker to the Java API service with OpenAPI documentation, and finally using the can-i-deploy tool to verify the changes in the web application
The lifecycle shows separate consumer and provider publications converging at the broker, followed by a deployment decision based on the comparison result. section 3.7.2
Web consumer and API provider
A JavaScript web application can publish a contract captured from its test mocks. Independently, a Java API service can publish tested OpenAPI documentation. PactFlow compares the two artifacts rather than running the consumer contract against the API code; the web team then uses can-i-deploy to decide whether its change is safe to release. section 3.7.2 section 11.4
Adapters support the workflow without requiring a new test framework. Consumer-side examples include Cypress, Mock Service Worker, Playwright, and WireMock; provider-side examples include Postman, Dredd, REST Assured, ReadyAPI, and SoapUI. The central trade-off is fidelity: compatibility is only as trustworthy as the uploaded consumer interactions and current provider specification. section 11.1.2 section 11.1.3
Choose PDCT after considering whether CDCT fits the project first. It can suit API-design-oriented workflows and teams constrained by third-party providers, but bi-directional testing is exclusive to PactFlow and was still a relatively new approach when introduced publicly in 2022. Keep provider specifications current and capture sufficient consumer interactions to avoid allowing breaking changes through. section 11.1.1 section 11.1.3
