A consumer can be ready to ship while its provider is owned by another team, uses a different stack, or already documents its API with OpenAPI. Bi-directional contract testing offers a way to check their compatibility without requiring both sides to adopt the same contract-testing framework or provider-test workflow. section 2.5.5 section 11.1
Bi-directional contract testing, also called provider-driven contract testing (PDCT), is static contract testing with two inputs: a consumer contract that represents expectations and a provider contract that represents capabilities. A broker compares them through cross-contract validation, checking whether the expected response shape is compatible with the provider’s actual response shape. section 3.7.2 section 11.1
This differs from traditional consumer-driven contract testing (CDCT). CDCT generates one contract, typically from consumer interactions with a mock provider, then verifies the provider against it. PDCT generates two contracts: consumers can derive theirs from existing mocks or stubs, while providers can upload an existing OpenAPI specification that has already been tested with their current tools. section 3.7.2 section 11.1
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
- Publish a provider contract, often generated from an OpenAPI specification and accompanied by provider test results. section 3.7.2 section 11.1
- Let PactFlow compare both contracts and record whether they are compatible. section 3.7.2 section 11.1
- Use can-i-deploy to check the verification status before deploying consumer or provider changes. section 3.7.2 section 11.1
JavaScript consumer and Java API provider
A JavaScript web application publishes a contract generated from its test mocks. Independently, a Java API or event service publishes its tested OpenAPI specification. PactFlow compares the consumer expectations with the provider specification; the web application then checks can-i-deploy before releasing its change. This keeps each side in its own testing setup while making compatibility visible in a shared broker. section 3.7.2
Figure 11.2 The PDCT life cycle, describing when the Pact broker compares consumer contract with the provider OpenAPI specification
The lifecycle diagram shows the central handoff: consumer and provider publish separate contracts, the broker compares them, and deployment is gated by the resulting compatibility status. section 11.1
PDCT can lower the time investment and learning curve of adopting contract testing because teams can adapt existing testing and mocking tools rather than replace them. It is especially useful where provider tests are difficult to add to another team’s pipeline. It does not replace CDCT; it is an easier adoption path when CDCT cannot be used. section 2.5.5 section 11.1
Keep its scope narrow: compatibility checks do not test all provider business logic or side effects, UI appearance or accessibility, performance, or security. Those concerns need their respective functional or specialized testing approaches. section 1.3
