Skip to content
Development
Skill

/contract-testing-patterns

Pact consumer-driven contracts, provider verification, schema evolution

From plugin
vibecosystem
534200 skills138 agents7 hooks
Install
$ npx -y skills add vibeeval/vibecosystem --skill contract-testing-patterns --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/contract-testing-patterns

Context preview

The summary Claude sees to decide when to auto-load this skill.

Pact consumer-driven contracts, provider verification, schema evolution

SKILL.md

contract-testing-patterns.SKILL.md
name: contract-testing-patterns
description: Pact consumer-driven contracts, provider verification, schema evolution

Contract Testing Patterns

Consumer-Driven Contract Testing with Pact

Consumer Test (JavaScript)

const { PactV3, MatchersV3 } = require('@pact-foundation/pact');
const { like, eachLike, string, integer } = MatchersV3;

const provider = new PactV3({
  consumer: 'OrderService',
  provider: 'UserService',
  logLevel: 'warn',
});

describe('User API Contract', () => {
  it('returns user by ID', async () => {
    await provider
      .given('user with ID 1 exists')
      .uponReceiving('a request for user 1')
      .withRequest({
        method: 'GET',
        path: '/api/users/1',
        headers: { Accept: 'application/json' },
      })
      .willRespondWith({
        status: 200,
        headers: { 'Content-Type': 'application/json' },
        body: {
          id: integer(1),
          name: string('Jane Doe'),
          email: string('jane@example.com'),
          roles: eachLike('admin'),
        },
      })
      .executeTest(async (mockServer) => {
        const client = new UserClient(mockServer.url);
        const user = await client.getUser(1);
        expect(user.id).toBe(1);
        expect(user.name).toBeDefined();
      });
  });
});

Provider Verification

const { Verifier } = require('@pact-foundation/pact');

describe('User Provider Verification', () => {
  it('validates consumer contracts', async () => {
    const verifier = new Verifier({
      providerBaseUrl: 'http://localhost:3000',
      pactBrokerUrl: process.env.PACT_BROKER_URL,
      pactBrokerToken: process.env.PACT_BROKER_TOKEN,
      provider: 'UserService',
      providerVersion: process.env.GIT_SHA,
      providerVersionBranch: process.env.GIT_BRANCH,
      publishVerificationResult: true,
      stateHandlers: {
        'user with ID 1 exists': async () => {
          await db.users.create({ id: 1, name: 'Jane Doe', email: 'jane@example.com' });
        },
        'no users exist': async () => {
          await db.users.deleteAll();
        },
      },
    });
    await verifier.verifyProvider();
  });
});

Schema Evolution Rules

# Backward Compatible (SAFE):
- Adding optional fields
- Adding new endpoints
- Widening accepted value ranges
- Adding new enum values (if consumer ignores unknown)

# Breaking Changes (UNSAFE):
- Removing fields
- Renaming fields
- Changing field types
- Making optional fields required
- Narrowing accepted value ranges
- Removing endpoints

Can-I-Deploy Check

# Before deploying consumer
pact-broker can-i-deploy \
  --pacticipant OrderService \
  --version $GIT_SHA \
  --to-environment production

# Before deploying provider
pact-broker can-i-deploy \
  --pacticipant UserService \
  --version $GIT_SHA \
  --to-environment production

Checklist

  • [ ] Every external API dependency has a consumer contract
  • [ ] Provider state handlers seed realistic test data
  • [ ] Contracts published to Pact Broker with git SHA version
  • [ ] `can-i-deploy` gate in CI pipeline before deploy
  • [ ] Provider verification runs on every PR
  • [ ] Breaking change detection automated
  • [ ] Contract tests run in under 30 seconds
  • [ ] Webhook configured to trigger provider verification on new pact

Anti-Patterns

  • Testing provider internal logic in consumer tests
  • Using exact matchers instead of type matchers (brittle)
  • Skipping provider states (tests pass but don't reflect reality)
  • Not versioning contracts with git SHA
  • Running contract tests against shared environments
  • Coupling consumer tests to provider implementation details
  • Ignoring `can-i-deploy` failures
Read more
Ships withvibecosystem

Your AI software team. Built on Claude Code. vibecosystem turns Claude Code into a full AI software team — 138 specialized agents that plan, build, review, test, and learn from every mistake. No configuration needed — just install and code.

Get the whole plugin

Other skills on vibecosystem.