API Testing

A comprehensive framework for testing REST and GraphQL APIs with confidence. Covers the full spectrum from unit-level handler tests to cross-service contract tests, with emphasis on what to test at each layer and why - not just syntax. Designed for engineers who can write tests but need opinionated guidance on strategy, tooling, and avoiding common traps.

---

When to use this skill

Trigger this skill when the user:

• Writes tests for a REST or GraphQL API endpoint
• Sets up integration or end-to-end tests for an HTTP service
• Implements contract testing between a consumer and provider
• Creates mock servers or stubs for downstream dependencies
• Validates response schemas or payload shapes
• Tests authentication flows (JWT, OAuth, API keys)
• Tests error handling, edge cases, or failure scenarios
• Asks about Supertest, Pact, MSW, Zod validation, or Apollo testing

Do NOT trigger this skill for:

• UI/component testing concerns (use a frontend-testing skill instead)
• Load/performance testing - that is a separate discipline with different tooling

---

Key principles

1. Test behavior, not implementation - Assert on what the API returns to callers, not on how internal functions are wired together. An endpoint test that reaches the router and asserts on status code + response body is worth ten unit tests on internal helpers.

2. Isolate at the right boundary - Unit tests mock everything below the handler. Integration tests use a real database (test container or in-memory). Contract tests verify only the interface promise. Choose the boundary that catches the most bugs with the least brittleness.

3. Schema-first assertions - Validate response shape with a schema (Zod, JSON Schema) rather than field-by-field assertions. One schema assertion catches structural regressions that 20 individual assertions would miss.

4. Contracts are promises, not snapshots - A contract test verifies that a provider will always satisfy what a consumer expects. It must be run on every deploy. A snapshot that drifts silently is worse than no test.

5. Mock at the network boundary, not inside functions - Use MSW or nock to intercept HTTP calls at the network layer. Mocking individual imported functions couples tests to implementation details and breaks on refactors.

---

Core concepts

API test types

Type	What it tests	Scope	Speed
Unit	Handler logic, middleware, validators	Single function	Fast
Integration	Full request cycle with real DB	Service in isolation	Medium
Contract	Interface promise between consumer + provider	Two services	Medium
End-to-end	Complete user journey across services	Full stack	Slow

Default strategy: Integration tests for business logic (they give the most confidence per line of test code). Unit tests for pure transformation logic. Contract tests at service boundaries. E2E only for the critical happy path.

Mock vs stub vs fake

Term	Definition	Use for
Mock	Records calls and verifies expectations	Verifying side effects (emails sent, events published)
Stub	Returns canned responses without recording	Replacing slow/expensive dependencies
Fake	Working implementation of a lighter version	In-memory DB, in-process message queue

Prefer fakes over stubs over mocks. Mocks that verify call counts are fragile and break whenever you refactor internal wiring.

Schema validation

Validate response schemas at the integration test level. Use Zod because it:

• Produces TypeScript types from the same definition (no duplication)
• Gives precise error messages when assertions fail
• Can be shared between test and production code for dual validation

---

Common tasks

Test REST endpoints with Supertest

Supertest binds directly to an Express/Fastify app without starting a real HTTP server. Use it for integration tests that exercise the full request pipeline.

// tests/users.test.ts
import request from 'supertest';
import { app } from '../src/app';
import { db } from '../src/db';

beforeEach(async () => {
  await db.migrate.latest();
  await db.seed.run();
});

afterEach(async () => {
  await db.migrate.rollback();
});

describe('GET /users/:id', () => {
  it('returns 200 with user data for a valid id', async () => {
    const res = await request(app)
      .get('/users/1')
      .set('Authorization', 'Bearer test-token')
      .expect(200);

    expect(res.body).toMatchObject({
      id: 1,
      email: expect.stringContaining('@'),
      createdAt: expect.any(String),
    });
  });

  it('returns 404 when user does not exist', async () => {
    const res = await request(app)
      .get('/users/99999')
      .set('Authorization', 'Bearer test-token')
      .expect(404);

    expect(res.body).toMatchObject({
      type: expect.stringContaining('not-found'),
      status: 404,
    });
  });

  it('returns 401 when no auth token is provided', async () => {
    await request(app).get('/users/1').expect(401);
  });
});

Test GraphQL APIs with Apollo Server Testing

Use @apollo/server test utilities to execute operations in-process. This avoids the overhead of HTTP while still exercising the full resolver chain.

// tests/graphql/users.test.ts
import { ApolloServer } from '@apollo/server';
import { typeDefs } from '../src/schema';
import { resolvers } from '../src/resolvers';
import { createTestContext } from './helpers/context';

let server: ApolloServer;

beforeAll(async () => {
  server = new ApolloServer({ typeDefs, resolvers });
  await server.start();
});

afterAll(async () => {
  await server.stop();
});

describe('Query.user', () => {
  it('returns user fields when authenticated', async () => {
    const { body } = await server.executeOperation(
      {
        query: `query GetUser($id: ID!) {
          user(id: $id) { id email createdAt }
        }`,
        variables: { id: '1' },
      },
      { contextValue: createTestContext({ userId: 'viewer-1' }) }
    );

    expect(body.kind).toBe('single');
    if (body.kind === 'single') {
      expect(body.singleResult.errors).toBeUndefined();
      expect(body.singleResult.data?.user).toMatchObject({
        id: '1',
        email: expect.any(String),
      });
    }
  });

  it('returns null for a user that does not exist', async () => {
    const { body } = await server.executeOperation(
      { query: `query { user(id: "nonexistent") { id } }` },
      { contextValue: createTestContext({ userId: 'viewer-1' }) }
    );

    if (body.kind === 'single') {
      expect(body.singleResult.data?.user).toBeNull();
    }
  });
});

Contract testing with Pact

For detailed Pact consumer and provider verification examples, see references/contract-and-auth-testing.md.

Mock APIs with MSW

MSW intercepts at the Service Worker level in browsers and at the network layer in Node.js. Use it to replace real API calls in tests without patching imports.

// tests/msw/handlers.ts
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get('https://api.example.com/users/:id', ({ params }) => {
    if (params.id === '404') {
      return HttpResponse.json({ type: 'not-found', status: 404 }, { status: 404 });
    }
    return HttpResponse.json({ id: params.id, email: 'test@example.com' });
  }),

  http.post('https://api.example.com/orders', async ({ request }) => {
    const body = await request.json();
    return HttpResponse.json({ id: 'order-1', ...body }, { status: 201 });
  }),
];

// tests/setup.ts
import { setupServer } from 'msw/node';
import { handlers } from './msw/handlers';

export const server = setupServer(...handlers);

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// Override handlers for a single test
it('handles API errors gracefully', async () => {
  server.use(
    http.get('https://api.example.com/users/1', () =>
      HttpResponse.json({ message: 'Internal Server Error' }, { status: 500 })
    )
  );
  // test code...
});

Validate response schemas with Zod

Define schemas once and use them in both production code and tests. A failed schema parse gives a precise error pointing to exactly which field is wrong.

// src/schemas/user.ts
import { z } from 'zod';

export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(['admin', 'user', 'viewer']),
  createdAt: z.string().datetime(),
  profile: z.object({
    displayName: z.string().min(1),
    avatarUrl: z.string().url().nullable(),
  }),
});

export type User = z.infer<typeof UserSchema>;

// tests/users.schema.test.ts
import request from 'supertest';
import { app } from '../src/app';
import { UserSchema } from '../src/schemas/user';

it('GET /users/:id response conforms to UserSchema', async () => {
  const res = await request(app)
    .get('/users/1')
    .set('Authorization', 'Bearer test-token')
    .expect(200);

  const result = UserSchema.safeParse(res.body);
  if (!result.success) {
    throw new Error(`Schema validation failed: ${result.error.message}`);
  }
});

// Validate a list response
it('GET /users response items conform to UserSchema', async () => {
  const res = await request(app).get('/users').expect(200);

  const listSchema = z.object({
    data: z.array(UserSchema),
    pagination: z.object({ nextCursor: z.string().nullable(), hasNextPage: z.boolean() }),
  });

  expect(() => listSchema.parse(res.body)).not.toThrow();
});

Test authentication flows

For detailed authentication flow test examples (missing token, expired token, wrong scope, valid token), see references/contract-and-auth-testing.md.

Test error handling and edge cases

Error paths are the most likely to be undertested. Cover 4xx and 5xx responses explicitly, including the shape of error bodies.

// tests/error-handling.test.ts
import request from 'supertest';
import { app } from '../src/app';
import { db } from '../src/db';

describe('Error handling', () => {
  it('returns RFC 7807 error format for 422 validation failures', async () => {
    const res = await request(app)
      .post('/users')
      .set('Authorization', 'Bearer test-token')
      .send({ email: 'not-an-email' })
      .expect(422);

    expect(res.body).toMatchObject({
      type: expect.stringContaining('validation'),
      title: expect.any(String),
      status: 422,
      errors: expect.arrayContaining([
        expect.objectContaining({ field: 'email' }),
      ]),
    });
  });

  it('returns 409 when creating a user with a duplicate email', async () => {
    await request(app)
      .post('/users')
      .set('Authorization', 'Bearer test-token')
      .send({ email: 'duplicate@example.com', password: 'secret123' })
      .expect(201);

    await request(app)
      .post('/users')
      .set('Authorization', 'Bearer test-token')
      .send({ email: 'duplicate@example.com', password: 'secret123' })
      .expect(409);
  });

  it('does not leak stack traces in 500 responses', async () => {
    jest.spyOn(db, 'query').mockRejectedValueOnce(new Error('DB connection lost'));

    const res = await request(app)
      .get('/users/1')
      .set('Authorization', 'Bearer test-token')
      .expect(500);

    expect(JSON.stringify(res.body)).not.toContain('Error:');
    expect(JSON.stringify(res.body)).not.toContain('at ');
    expect(res.body.status).toBe(500);
  });

  it('returns 400 for malformed JSON body', async () => {
    await request(app)
      .post('/users')
      .set('Authorization', 'Bearer test-token')
      .set('Content-Type', 'application/json')
      .send('{ invalid json }')
      .expect(400);
  });
});

---

Anti-patterns

Mistake	Why it's wrong	What to do instead
Testing only the happy path	Error paths are where bugs live in production; clients rely on error contracts too	Cover 401, 403, 404, 409, 422, 500 for every resource
Mocking the module under test	Circular: if you mock the handler, you're not testing the handler	Mock dependencies (DB, HTTP calls), not the code being tested
Sharing state between tests	One test leaks data into the next; flaky tests that fail in suites but pass alone	Seed and tear down in beforeEach/afterEach; use transactions that roll back
Contract tests that are just snapshots	Snapshots catch no semantic regressions; they auto-update and drift silently	Use Pact with structured matchers; run provider verification in CI
Testing internal implementation details	Tests break on refactors even when behavior is unchanged; slows iteration	Test via the public HTTP interface; verify outputs, not internal calls
Ignoring response headers	Security and cache headers are part of the contract; clients depend on them	Assert Content-Type, Cache-Control, X-Request-Id, and auth headers

---

Gotchas

1. Shared test database state causes flaky tests - Tests that don't clean up after themselves leave rows that cause unique constraint failures or wrong counts in subsequent tests. The tests pass in isolation but fail in suites. Use database transactions that roll back after each test, or seed and truncate in beforeEach/afterEach.

2. MSW onUnhandledRequest: 'warn' silently passes unmocked calls - With the default warn setting, any request not matched by a handler goes through to the real network. In CI this causes non-deterministic test behavior. Set onUnhandledRequest: 'error' so unmatched requests fail loudly.

3. Supertest doesn't start a real server but shares app state - Supertest binds to the app instance. If the app has module-level singletons (connection pools, caches), those persist across tests. Make sure database and cache connections are properly reset between test runs, or tests will interfere with each other.

4. Pact consumer tests passing doesn't mean provider will pass - Consumer Pact tests only verify that the mock returns the expected shape. The provider verification step (running against the real provider) is where real contract drift is caught. Both steps must run in CI; running only the consumer half gives false confidence.

5. Schema validation with .toMatchObject() misses extra fields - Jest's toMatchObject does a partial match: extra fields on the response body pass silently. If the API starts leaking sensitive fields (passwords, internal IDs), these tests won't catch it. Use Zod's strict() mode or exact schema validation for security-sensitive fields.

---

References

For detailed patterns on specific tools and setups, read the relevant file from the references/ folder:

• references/msw-patterns.md - MSW setup for Node.js and browser environments, handler patterns, and recipes for common scenarios
• references/contract-and-auth-testing.md - Pact consumer/provider contract testing and authentication flow test examples

Only load a references file when the current task requires it - they are detailed and will consume context.