What it does
Records the web app's expectations as consumer contracts, verifies them against the API as a provider, and runs a can-i-deploy compatibility-matrix gate so a red matrix blocks deploy. Backstops API mocking by holding virtualized interfaces honest. Logs any contract mismatch as a defect.
When to use it
For contract testing across the integration boundary between the web app and the REST API.
Prerequisites
qa.config.yml with tooling.contract set, tooling.contract_broker_url, stack.api_spec_path, environments, gates, risk_areas.
Output
ISO/IEC/IEEE 29119-3 Test Execution Log -> docs_dir/CONTRACT-RESULTS-<scope>.md, with raw output under reports_dir and an Incident (Defect) Report per mismatch.
Mechanics
How it works
- Read config; gate that tooling.contract is enabled
- Resolve mode from arguments (consumer/provider/can-i-deploy; default full flow)
- Consumer: record web expectations from the API spec and publish pacts to the broker
- Provider: replay pacts against the API with provider states; log mismatches as defects
- can-i-deploy: query the broker matrix and emit a deploy/hold decision
- Wire CI triggers and explain how contracts backstop API mocking
Why it works
The theory behind it
Implementation and execution at the component/system integration level (CTFL §2.2; CT-TAE). Contracts catch integration breakage without a full integrated environment — the cheap place to find interface defects.
CTFL v4.0 §2.2 (integration testing) · CT-TAE (Specialist)
Example
See it in use
> /qa:contract-sync can-i-deploy✓ Correct when It talks to the configured contract_broker_url and gates deploy on verified contracts.
Used by