contract-testing — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited contract-testing (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
What it is: Contract testing verifies that consumers and providers remain compatible by turning interface expectations into executable contracts that providers replay and publish as verification results.
Mental model: A consumer records the smallest meaningful promise it relies on, the provider proves that promise still holds, and a broker or CI gate answers whether the relevant versions can deploy together.
Why it exists: It protects service boundaries without relying on slow, brittle cross-service end-to-end suites or treating a schema as proof that real consumer behavior is safe.
What it is NOT: It is not a replacement for provider integration tests, user-journey end-to-end tests, property-based testing, or API design governance.
Adjacent concepts: API design, system interface contracts, event contract design, integration test design, test doubles, deploy gates.
One-line analogy: Contract testing is a lease agreement for an interface: each side can change internally, but shared obligations must still be honored.
Common misconception: Pact-style tests are not valuable because they mock providers; the provider replay and published verification result are the part that turns mocks into deploy confidence.
The technique of verifying interfaces between consumer and provider components by capturing the consumer's expectations as a contract artifact and running that contract against both sides independently. Covers the consumer-driven contracts pattern (Fowler 2006; Pact ecosystem), the two-phase verification (consumer-side mock generation; provider-side replay), the broker as the integration point that enables deploy independence and compatibility tracking, the contrast with schema-only validation (OpenAPI captures surface; contracts capture behavior), the contrast with integration and e2e testing (contracts verify the interface; integration and e2e verify implementation and journeys), and the tool ecosystem (Pact, Spring Cloud Contract, Specmatic, API-spec-driven patterns).
Contract testing decouples deploy schedules between services. Before contract testing, two services that depended on each other had to be tested together — usually with brittle cross-service e2e tests in a shared staging environment, which serialized deploys and produced flaky signal. With contract testing, each side is verified independently against a shared contract; deploys can happen on independent schedules as long as the contract is satisfied.
The contract is consumer-driven: it captures what the consumer actually does, not what the provider offers. This narrowing — three endpoints out of fifty, twelve fields out of a hundred — is what makes contract testing focused and what distinguishes it from full schema validation. The provider can change anything the consumers don't rely on; the provider cannot break anything any consumer's contract requires.
The discipline is in the broker. A contract-test setup without a broker is "contracts as committed fixtures" — much of the maintenance cost, little of the deploy-independence benefit. A contract-test setup with a broker (Pact Broker, PactFlow) provides versioned contract storage, compatibility tracking, and deploy-gating; the strategic value of the technique is realized at this layer.
┌─────────────────────────┐ ┌─────────────────────────┐
│ Consumer's CI │ │ Provider's CI │
│ │ │ │
│ 1. Run consumer tests │ │ 4. Fetch contracts │
│ against generated │ │ from broker │
│ mock provider │ │ │
│ │ │ 5. Replay each contract │
│ 2. If pass: contract │ │ against real │
│ is correct │ │ provider │
│ │ │ │
│ 3. Publish contract │ │ 6. If pass: provider │
│ to broker │ ──────▶ │ satisfies contract │
│ │ │ │
│ │ ◀────── │ 7. Mark contract version│
│ │ broker │ as verified │
└─────────────────────────┘ └─────────────────────────┘When both sides have passed independently, the broker records the compatibility. Deploy gating uses this record: don't deploy the provider unless its current version is marked compatible with the production consumer's contract.
| Property | OpenAPI / JSON Schema | Consumer-driven contract |
|---|---|---|
| Captures | Surface (endpoints, types, shapes) | Behavior (specific interactions the consumer performs) |
| Driven by | Provider | Consumer |
| Coverage | Everything the provider offers | Only what consumers use |
| Catches breaking field value change | If schema constrains values; usually not | Yes — the contract has specific values |
| Catches semantic / error-shape change | No | Yes if consumer relies on the error |
| Verifies through real implementation | No (validates response against schema only) | Yes (provider runs the contract against itself) |
| Used for | API description, code generation, validation | Test gate between consumer and provider |
| Should you have both? | Yes | Yes |
| Pre-contract-testing approach | Contract-testing replacement | When replacement is right |
|---|---|---|
| Cross-service e2e test for service boundary | Contract test | Almost always — cheaper, more reliable, doesn't require both services running |
| Schema validation alone | Contract test + schema | Always — schema is necessary but not sufficient |
| Coordinated deploy schedules | Independent deploys + broker gating | Almost always — the deploy-independence is the strategic value |
| Manual API change reviews | Contract verification on provider CI | Always — the verification is automated |
| "We'll catch it in staging" | Contract test on PR | Always — catching at PR time is much cheaper |
| State | Can deploy? |
|---|---|
| Provider version has been verified against current production consumer contract | Yes |
| Provider version has not yet been verified against current production consumer contract | No — run verification first |
| Provider version fails verification against production consumer contract | No — fix or coordinate with consumer |
| Consumer version's contract has not been verified against current production provider | No — run provider verification |
The broker's compatibility matrix is the deploy gate. Modern setups (PactFlow, Pact Broker can-i-deploy API) automate this; the deploy pipeline calls the broker and gets a yes/no answer.
After applying this skill, verify:
| Instead of this skill | Use | Why |
|---|---|---|
| Testing the implementation behind a service interface | integration-test-design | integration tests verify in-service behavior; contracts verify the interface |
| Testing a user journey across the whole stack including UI | e2e-test-design | e2e tests verify the user experience; contracts verify the service boundary |
| Validating responses against an OpenAPI schema | OpenAPI/JSON-Schema validation tooling | schema validation captures surface; this skill captures behavior |
| Testing a single unit in isolation | testing-strategy + test-doubles-design | unit scope is below this skill's level |
| Designing the API surface itself | api-design | api-design owns the contract design; this skill owns the verification |
| Designing the event surface | event-contract-design | event-contract-design owns the asynchronous contract design; this skill verifies it |
| Choosing the test-level ratio | testing-strategy | strategy owns ratios; this skill owns the contract-testing technique |
<!-- skill-graph-context:start (generated — do not edit by hand) -->
Classification
quality-assurancetruequality/testingWhen to use
should this be a contract test or an integration test, Pact vs OpenAPI, how do we decouple deploys between services, the consumer broke when the provider changed, should we e2e test across servicesNot for
integration-test-design: interface verificatione2e-test-designRelated skills
api-design, integration-test-design, testing-strategyevent-contract-design, system-interface-contracts, testing-strategy, integration-test-design, e2e-test-design, api-designConcept
Grounding
universalhttps://martinfowler.com/articles/consumerDrivenContracts.html, https://docs.pact.io/implementation_guides/javascript/docs/provider, https://docs.pact.io/pact_broker, https://docs.pact.io/pact_broker/can_i_deploy, https://docs.spring.io/spring-cloud-contract/docs/current/reference/html/index.html, https://docs.specmatic.io/contract_driven_development/contract_testing, skills/quality-assurance/contract-testing/references/upstream-displacement-2026-06-09.mdKeywords
contract testing, consumer-driven contracts, Pact, Spring Cloud Contract, Specmatic, contract broker, provider verification, consumer test, CDC, OpenAPI conformance<!-- skill-graph-context:end -->
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.