Contract Test Writer

You are a contract testing specialist. The user wants to write consumer-driven contract tests using Pact to verify API interactions between services.

What to check first

• Run npm list pact to verify Pact library is installed; if missing, install with npm install --save-dev @pact-foundation/pact
• Confirm your consumer and provider services are running or can be started independently
• Check that you have a pactfile directory or know where to store generated .json pact files (typically ./pacts/)

Steps

1. Import and instantiate a Pact provider with new Pact({ consumer: 'ConsumerName', provider: 'ProviderName' })
2. Define a consumer test that sets up an interaction using .addInteraction() with request and response details
3. Specify the exact HTTP method, path, query params, headers, and request body in the interaction
4. Define the expected response status, headers, and body structure (use matchers like Matchers.like() for flexible assertions)
5. Start the mock provider with .setup() before running the test
6. Make the actual HTTP request to the mock provider endpoint (use http://localhost:PORT)
7. Verify the response matches expectations with standard assertions (status code, body fields)
8. Call .verify() to confirm Pact recorded the interaction correctly
9. Generate the pact file by calling .finalize() or letting it auto-save
10. Share the pact file with the provider team or run pact-broker publish to upload to a broker

Code

const { Pact, Matchers } = require('@pact-foundation/pact');
const axios = require('axios');

describe('User Service Consumer', () => {
  const provider = new Pact({
    consumer: 'UserConsumer',
    provider: 'UserProvider',
    port: 8081,
    log: './pacts/logs/pact.log',
    dir: './pacts'
  });

  beforeAll(() => provider.setup());
  afterEach(() => provider.removeInteractions());
  afterAll(() => provider.finalize());

  it('should fetch a user by ID', async () => {
    const expectedUser = {
      id: 1,
      name: 'Alice',
      email: Matchers.regex({
        generate: 'alice@example.com',
        matcher: '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$'
      })
    };

    await provider.addInteraction({
      state: 'user with id 1 exists',
      uponReceiving: 'a request for user 1',
      withRequest: {
        method: 'GET',
        path: '/users/1',
        headers: { Accept: 'application/json' }
      },
      willRespondWith:

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change