Contract Testing: Pact and Schema-Based Testing

Consumer-driven contract testing (Pact) records what each consumer actually uses as contracts; the provider's CI verifies it still satisfies every consumer — catching breaking changes that matter in practice. Schema-based testing validates implementations against the OpenAPI spec and generates many requests (Schemathesis, Dredd) to find crashes and spec violations. Bi-directional contract testing (PactFlow) compares consumer expectations with the provider's OpenAPI spec.

Testing approaches

const provider = new PactV3({ consumer: "web-app", provider: "orders-api" });

it("gets an order", () =>
  provider
    .given("order ord_1 exists")
    .uponReceiving("a request for order ord_1")
    .withRequest({ method: "GET", path: "/v1/orders/ord_1" })
    .willRespondWith({ status: 200, body: like({ id: "ord_1", status: "paid", total: { amount: 2400, currency: "EUR" } }) })
    .executeTest(async (mock) => {
      const order = await getOrder(mock.url, "ord_1");
      expect(order.status).toBe("paid");
    }));

# Generate requests from the OpenAPI spec and check responses conform
schemathesis run https://staging.example.com/openapi.json \
  --checks all --header "Authorization: Bearer $TOKEN" --max-examples 200

Common pitfalls

• Contracts that assert exact values instead of shapes/matchers.
• Provider states that are hard to set up.
• Relying only on end-to-end tests for compatibility.

Key points

• Pact verifies real consumer usage
• Schemathesis fuzzes against the spec
• Both run in CI without full environments

Further reading: Pact documentation