backend-contract-testing

Backend Contract Testing

Purpose

Use consumer-driven contract (CDC) testing with Pact to verify that provider services satisfy consumer expectations, replacing brittle end-to-end integration tests with fast, deterministic contract tests.

Agent Protocol

Trigger

Exact user phrases: "contract testing", "Pact", "consumer-driven contracts", "CDC", "provider verification", "pact test", "pactflow", "contract test", "consumer test", "provider test".

Input Context

• Service architecture: list of consumers and providers.
• Existing test framework (Jest, JUnit, pytest, etc.).
• Pact broker or PactFlow URL if available.

Output Artifact

Pact test code snippets or Pactfile. No file unless requested.

Response Format

Consumer: {service}
Provider: {service}
Interactions: {N}
State: {provider state}

Completion Criteria

• Consumer test written for each consumer-provider interaction.
• Provider verification test written for each provider.
• Pact files published to Pact broker.
• Provider verification runs in CI against the deployed provider.
• No hardcoded URLs or real data in Pact tests.

Max Response Length

6 lines per interaction. 20 lines for full test.

Architecture Decision Tree

Should I Use Contract Testing?

Do consumer and provider belong to different teams?
  ├── Yes → Strongly consider contract testing
  └── No → Is the provider used by multiple consumers?
            ├── Yes → Contract testing recommended
            └── No → Would an E2E test be too slow/brittle?
                      ├── Yes → Contract testing may help
                      └── No → Simple unit/integration tests may suffice

Which Approach?

Can the consumer change the contract independently?
  ├── Yes → Consumer-Driven Contract (CDC) with Pact
  └── No → Is the provider owned by the same team as the consumer?
            ├── Yes → Bi-Directional Contracts (Spring Cloud Contract or Pact)
            └── No → Provider-Driven Contracts (OpenAPI + Specmatic)