API Testing Strategies for 2026

APIs need four types of tests. Unit tests verify individual functions. Integration tests verify endpoints work correctly. Contract tests verify the API matches its specification. End-to-end tests verify complete workflows. Here's when to use each and which tools to choose.

TL;DR

• Integration tests are the highest-value investment for APIs: they test the actual HTTP contract, auth, and database interactions — not mocks
• Testcontainers is the right tool for spinning up real databases in CI — Docker containers that start clean for every test run
• Prism + Spectral for contract testing: mock server during development, validate responses against OpenAPI spec in CI
• k6 is the best load testing tool for APIs in 2026: JavaScript test scripts, CI-friendly, threshold-based pass/fail
• Testing authentication and authorization (not just happy paths) catches the security bugs that matter most in production
• MSW (Mock Service Worker) for mocking external HTTP APIs in tests — it's more reliable than nock and works in both Node.js and browser environments

The API Testing Pyramid

        ╱╲
       ╱ E2E ╲           Few, slow, expensive
      ╱────────╲
     ╱ Contract  ╲       Medium, catch breaking changes
    ╱──────────────╲
   ╱  Integration   ╲    Many, verify endpoints
  ╱──────────────────╲
 ╱      Unit          ╲  Most, fast, cheap
╱──────────────────────╲

Unit Tests

Test individual functions in isolation — validation logic, data transformation, business rules. Mock external dependencies.

What to test:

• Input validation (does it reject bad data?)
• Business logic (does the calculation work?)
• Error handling (does it throw the right error?)
• Data transformation (does the mapper produce correct output?)

Tools: Jest, Vitest, pytest, Go testing

Example: Test that a price calculation function correctly applies discounts, taxes, and currency conversion — without hitting a database or API.

Integration Tests

Test API endpoints with real (or realistic) dependencies — database, cache, external services. The most important test type for APIs.

What to test:

• Endpoint returns correct status codes
• Response body matches expected schema
• Authentication works (valid/invalid/missing tokens)
• Authorization works (user A can't access user B's data)
• Pagination works correctly
• Error responses are properly formatted
• Database changes are persisted

Tools: Supertest (Node.js), pytest + httpx (Python), net/http/httptest (Go), REST Assured (Java)

Pattern:

1. Set up test database with seed data
2. Make HTTP request to endpoint
3. Assert status code, response body, headers
4. Assert database state changed correctly
5. Clean up

Contract Tests

Verify your API matches its documented contract (OpenAPI spec). Catch breaking changes before they reach production.

What to test:

• Response schema matches OpenAPI spec
• Required fields are present
• Field types are correct
• Enum values are valid
• New endpoints are documented
• Removed endpoints are deprecated first

Tools:

Tool	Type	Description
Prism	Mock + validate	Mock server from OpenAPI, validate requests/responses
Dredd	Contract testing	Test real API against OpenAPI/API Blueprint
Schemathesis	Property-based	Generate test cases from OpenAPI spec
Pact	Consumer-driven	Contracts defined by API consumers
Spectral	Lint	Lint OpenAPI specs for design rules

Consumer-Driven Contracts (Pact)

API consumers define what they expect. The API provider verifies against consumer expectations. If the provider changes break a consumer's contract, tests fail before deployment.

End-to-End Tests

Test complete user workflows that span multiple API calls:

1. Create user (POST /users)
2. Login (POST /auth/login)
3. Create order (POST /orders)
4. Process payment (POST /payments)
5. Check order status (GET /orders/123)
6. Verify webhook received

What to test:

• Complete business workflows
• Multi-step operations
• Webhook delivery
• Async job completion
• Cross-service interactions

Tools: Playwright (for API + UI), custom scripts, Postman collections, k6 (load + functional)

Warning: E2E tests are slow, flaky, and expensive. Write fewer of them. Test critical paths only (signup, checkout, payment).

Test Environment Strategy

Environment	Purpose	Data
Local	Unit + integration tests	In-memory DB or Docker
CI/CD	All test types	Ephemeral test databases
Staging	E2E + contract	Seed data, sandbox APIs
Production	Smoke tests only	Real data, read-only tests

Testing Checklist

Every Endpoint Should Have Tests For:

• Happy path (valid request → expected response)
• Authentication (missing, invalid, expired token)
• Authorization (user accessing other user's data)
• Validation (missing required fields, invalid types, boundary values)
• Not found (requesting non-existent resources)
• Rate limiting (verify 429 is returned)
• Error response format (consistent error schema)

API-Wide Tests:

• All endpoints require authentication (no open endpoints by accident)
• Response schemas match OpenAPI spec
• CORS headers are correct
• Security headers are present
• Rate limit headers are included

Integration Testing with Supertest and Testcontainers

The common shortcut in integration testing is using an in-memory SQLite database or mocking the data layer entirely. The problem: in-memory databases don't behave identically to production PostgreSQL. Indexes, constraints, and query planner behavior differ. You can have tests that pass but code that fails in production.

Testcontainers solves this by spinning up a real Docker PostgreSQL container for each test run. Tests run against real database behavior, and the container tears down after tests complete.

Complete Test File Example

import { GenericContainer, StartedTestContainer } from 'testcontainers';
import { Pool } from 'pg';
import request from 'supertest';
import { app } from '../src/app';
import { runMigrations } from '../src/db/migrations';

describe('Users API', () => {
  let pgContainer: StartedTestContainer;
  let pool: Pool;

  beforeAll(async () => {
    // Start PostgreSQL container
    pgContainer = await new GenericContainer('postgres:16')
      .withEnvironment({
        POSTGRES_USER: 'test',
        POSTGRES_PASSWORD: 'test',
        POSTGRES_DB: 'testdb',
      })
      .withExposedPorts(5432)
      .start();

    const connectionString = `postgresql://test:test@${pgContainer.getHost()}:${pgContainer.getMappedPort(5432)}/testdb`;

    pool = new Pool({ connectionString });
    process.env.DATABASE_URL = connectionString;

    // Run migrations against real PostgreSQL
    await runMigrations(pool);
  }, 60_000); // Allow 60s for container to start

  afterAll(async () => {
    await pool.end();
    await pgContainer.stop();
  });

  beforeEach(async () => {
    // Clean between tests for isolation
    await pool.query('TRUNCATE TABLE users CASCADE');
  });

  describe('POST /api/users', () => {
    it('creates a user with valid data', async () => {
      const res = await request(app)
        .post('/api/users')
        .set('Authorization', `Bearer ${testToken}`)
        .send({ name: 'Alice', email: 'alice@example.com' });

      expect(res.status).toBe(201);
      expect(res.body.id).toBeDefined();
      expect(res.body.email).toBe('alice@example.com');

      // Verify database state
      const { rows } = await pool.query('SELECT * FROM users WHERE email = $1', ['alice@example.com']);
      expect(rows).toHaveLength(1);
      expect(rows[0].name).toBe('Alice');
    });

    it('returns 409 on duplicate email', async () => {
      await pool.query("INSERT INTO users (name, email) VALUES ('Existing', 'alice@example.com')");

      const res = await request(app)
        .post('/api/users')
        .set('Authorization', `Bearer ${testToken}`)
        .send({ name: 'Alice', email: 'alice@example.com' });

      expect(res.status).toBe(409);
      expect(res.body.code).toBe('email_already_exists');
    });

    it('returns 400 on invalid email', async () => {
      const res = await request(app)
        .post('/api/users')
        .set('Authorization', `Bearer ${testToken}`)
        .send({ name: 'Alice', email: 'not-an-email' });

      expect(res.status).toBe(400);
      expect(res.body.code).toBe('validation_error');
      expect(res.body.issues[0].path).toContain('email');
    });
  });

  describe('GET /api/users/:id', () => {
    it('returns 404 for non-existent user', async () => {
      const res = await request(app)
        .get('/api/users/non-existent-id')
        .set('Authorization', `Bearer ${testToken}`);

      expect(res.status).toBe(404);
    });
  });
});

The TRUNCATE TABLE users CASCADE before each test ensures clean state. CASCADE handles foreign key dependencies — users referencing orders, for example. This is faster than re-seeding the entire database and more reliable than trying to clean up after each test.

Testcontainers works with Jest, Vitest, Mocha, and any Node.js test runner. The container startup time (~5-10s) happens once in beforeAll, not per test. For CI, ensure Docker is available in your runner. GitHub Actions provides Docker by default.

Contract Testing with Prism

Prism serves two purposes: mock server (run your API locally without real implementations, useful during development) and validation proxy (forward requests to your real API and validate that responses match the OpenAPI spec).

The validation proxy mode is the key contract testing pattern:

# Install Prism
npm install -g @stoplight/prism-cli

# Start Prism as a validation proxy
prism proxy api.yaml http://localhost:3000 --port 4000

Now route your tests through http://localhost:4000 instead of http://localhost:3000. Prism forwards every request and validates every response. If your API returns a field that isn't in the spec, Prism logs a warning. If it returns the wrong type, Prism logs an error.

Running Validation in CI

# .github/workflows/contract-tests.yml
steps:
  - name: Start API server
    run: npm run start:test &
    
  - name: Wait for API to be ready
    run: npx wait-on http://localhost:3000/health
    
  - name: Run tests via Prism proxy
    run: |
      npx prism proxy api.yaml http://localhost:3000 --port 4000 &
      sleep 2
      TEST_BASE_URL=http://localhost:4000 npm test
      
  - name: Check Prism output for validation errors
    run: # Parse Prism logs for contract violations

Dredd for Automated Contract Testing

Dredd reads your OpenAPI spec and automatically generates test requests for each endpoint, validating responses against the spec:

dredd api.yaml http://localhost:3000 --reporter html --output report.html

Dredd tests every documented endpoint with the example values from the spec. For endpoints that require authentication or specific data setup, Dredd supports hooks:

// dredd-hooks.js
const hooks = require('hooks');

hooks.before('/api/users > POST', function(transaction, done) {
  transaction.request.headers['Authorization'] = 'Bearer test-token';
  done();
});

For the OpenAPI documentation tooling that powers these contract tests, see API documentation: OpenAPI vs AsyncAPI.

Load Testing APIs

Load testing reveals how your API behaves under pressure. The questions you need answered before production: What's the max request rate before latency degrades? What's the breaking point? Where are the bottlenecks (database, external calls, CPU)?

k6 for API Load Testing

k6 is the best load testing tool for APIs in 2026. Test scripts are JavaScript, results are structured, and CI integration is straightforward:

// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  // Ramp up to 100 VUs over 30s, stay there for 1 minute, ramp down
  stages: [
    { duration: '30s', target: 100 },
    { duration: '1m', target: 100 },
    { duration: '30s', target: 0 },
  ],
  thresholds: {
    // Fail if p95 latency exceeds 500ms
    http_req_duration: ['p(95)<500'],
    // Fail if error rate exceeds 1%
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/api/users', {
    headers: { Authorization: 'Bearer ${__ENV.TEST_TOKEN}' },
  });

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });

  sleep(1); // Think time between requests
}

Run the load test:

k6 run --env TEST_TOKEN=your-token load-test.js

Thresholds and Pass/Fail in CI

The thresholds configuration makes load tests CI-friendly. If any threshold fails, k6 exits with a non-zero code — the CI job fails. This prevents performance regressions from shipping:

- name: Load test
  run: k6 run --env TEST_TOKEN=${{ secrets.TEST_TOKEN }} load-test.js

Identifying Bottlenecks

When a load test shows latency degradation at 50 VUs, where is the bottleneck? Common sources:

Database connection pool saturation. Add database query timing to your metrics. If queries are fast but response times are slow, the pool is exhausted. PgBouncer or increasing pool size fixes this.

External API calls. If your endpoint calls an external API (payment processor, email service), it serializes at scale. Cache responses where possible; use async processing for non-critical calls.

CPU-bound operations. Heavy JSON serialization, encryption, or computation blocks Node.js's event loop. Profile with Node's built-in profiler.

Track p50, p95, and p99 latencies — not averages. An average of 100ms with a p99 of 3000ms means 1% of users experience 3-second responses. See API rate limiting best practices for protecting your API once load testing reveals its limits.

Testing Authentication and Authorization

Authentication and authorization bugs are the security vulnerabilities that matter. A broken business logic test means wrong data; a broken auth test means data leaks to the wrong users.

Testing JWT Authentication

describe('JWT Authentication', () => {
  it('rejects requests without Authorization header', async () => {
    const res = await request(app).get('/api/profile');
    expect(res.status).toBe(401);
    expect(res.body.code).toBe('missing_token');
  });

  it('rejects malformed tokens', async () => {
    const res = await request(app)
      .get('/api/profile')
      .set('Authorization', 'Bearer not.a.valid.jwt');
    expect(res.status).toBe(401);
    expect(res.body.code).toBe('invalid_token');
  });

  it('rejects expired tokens', async () => {
    // Generate a token that expired 1 hour ago
    const expiredToken = jwt.sign(
      { userId: 'user_123' },
      process.env.JWT_SECRET!,
      { expiresIn: '-1h' }
    );
    const res = await request(app)
      .get('/api/profile')
      .set('Authorization', `Bearer ${expiredToken}`);
    expect(res.status).toBe(401);
    expect(res.body.code).toBe('token_expired');
  });

  it('rejects tokens signed with wrong secret', async () => {
    const wrongToken = jwt.sign(
      { userId: 'user_123' },
      'wrong-secret'
    );
    const res = await request(app)
      .get('/api/profile')
      .set('Authorization', `Bearer ${wrongToken}`);
    expect(res.status).toBe(401);
  });
});

Tenant Data Isolation (Critical Multi-Tenant Test)

For multi-tenant APIs, the isolation test is the most important security test you can write. See building multi-tenant APIs for the full isolation testing pattern:

it('user cannot access another user\'s resources', async () => {
  const userA = await createTestUser();
  const userB = await createTestUser();
  const userAOrder = await createOrder({ userId: userA.id });

  const tokenB = signToken({ userId: userB.id });

  const res = await request(app)
    .get(`/api/orders/${userAOrder.id}`)
    .set('Authorization', `Bearer ${tokenB}`);

  // 404, not 403 — don't confirm the order exists
  expect(res.status).toBe(404);
});

RBAC Verification

describe('Role-Based Access Control', () => {
  it('admins can access all users', async () => {
    const adminToken = signToken({ userId: adminUser.id, role: 'admin' });
    const res = await request(app)
      .get('/api/admin/users')
      .set('Authorization', `Bearer ${adminToken}`);
    expect(res.status).toBe(200);
  });

  it('regular users cannot access admin endpoints', async () => {
    const userToken = signToken({ userId: regularUser.id, role: 'user' });
    const res = await request(app)
      .get('/api/admin/users')
      .set('Authorization', `Bearer ${userToken}`);
    expect(res.status).toBe(403);
  });

  it('read-only users cannot perform write operations', async () => {
    const readonlyToken = signToken({ userId: readonlyUser.id, role: 'readonly' });
    const res = await request(app)
      .post('/api/users')
      .set('Authorization', `Bearer ${readonlyToken}`)
      .send({ name: 'New User', email: 'new@example.com' });
    expect(res.status).toBe(403);
  });
});

These tests catch the common mistake of implementing authentication (is the user logged in?) without implementing authorization (is this user allowed to do this?). For comprehensive security testing, see the API security checklist.

Mocking External APIs in Tests

Integration tests that call real external APIs are slow, flaky, and create test data in third-party systems. Mock external HTTP calls in tests.

MSW (Mock Service Worker) for Node.js

MSW intercepts HTTP requests at the network level — no patching of fetch or axios needed. The same mock handlers work in Node.js (for API testing) and browser (for frontend testing):

import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

// Define handlers
const handlers = [
  http.post('https://api.stripe.com/v1/payment_intents', () => {
    return HttpResponse.json({
      id: 'pi_test_123',
      status: 'succeeded',
      amount: 2000,
      currency: 'usd',
    });
  }),

  http.post('https://api.sendgrid.com/v3/mail/send', () => {
    return new HttpResponse(null, { status: 202 });
  }),

  http.get('https://api.github.com/users/:username', ({ params }) => {
    return HttpResponse.json({
      login: params.username,
      id: 12345,
      name: 'Mock User',
    });
  }),
];

const server = setupServer(...handlers);

// Setup/teardown in test suite
beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

// Test that actually exercises your code
it('creates a payment and sends confirmation email', async () => {
  const res = await request(app)
    .post('/api/orders')
    .set('Authorization', `Bearer ${testToken}`)
    .send({ amount: 2000, currency: 'usd' });

  expect(res.status).toBe(201);
  expect(res.body.paymentId).toBe('pi_test_123');
  // Stripe and SendGrid calls were intercepted by MSW
});

The onUnhandledRequest: 'error' option makes tests fail loudly if your code tries to call an external API that isn't mocked. This prevents tests from accidentally hitting real APIs.

Testing Error Responses from External APIs

MSW makes it easy to test how your code handles external API failures — a pattern that's hard to test without mocking:

it('handles Stripe payment failure gracefully', async () => {
  server.use(
    http.post('https://api.stripe.com/v1/payment_intents', () => {
      return HttpResponse.json(
        {
          error: {
            type: 'card_error',
            code: 'card_declined',
            message: 'Your card was declined.',
          },
        },
        { status: 402 }
      );
    })
  );

  const res = await request(app)
    .post('/api/orders')
    .set('Authorization', `Bearer ${testToken}`)
    .send({ amount: 2000 });

  expect(res.status).toBe(402);
  expect(res.body.code).toBe('payment_failed');
});

nock for Legacy Code

If your codebase uses Node.js http/https modules or older HTTP clients, nock is the established alternative:

import nock from 'nock';

nock('https://api.stripe.com')
  .post('/v1/payment_intents')
  .reply(200, { id: 'pi_test_123', status: 'succeeded' });

nock intercepts at the Node.js http module level. It doesn't work in browsers, which is why MSW (which works in both) is preferred for new projects.

The Case Against Over-Mocking

Mocking every dependency in integration tests defeats the purpose of integration testing. The value of integration tests comes from testing the real interactions between components. Over-mocked tests are really unit tests with more setup.

Mock only what crosses external process boundaries: HTTP calls to third-party APIs, payment processors, email providers. Don't mock your own database — use Testcontainers or an in-memory SQLite database configured for test mode. Don't mock your own service functions — test their actual behavior.

The rule of thumb: if you can spin it up in Docker (PostgreSQL, Redis, Elasticsearch), use the real thing. If it requires network access to a third-party service (Stripe, SendGrid, Twilio), mock it.

For the API design patterns that these testing strategies verify, see how to design a REST API developers love and API error handling and status codes.

Conclusion

A mature API testing strategy has clear layers: unit tests for isolated logic, integration tests with real databases (via Testcontainers) for endpoint behavior, contract tests (Prism + oasdiff) to prevent breaking changes, and load tests (k6) to establish performance baselines. Authentication and authorization tests are the highest-value security investment — they catch the bugs that matter most. Mock external HTTP calls with MSW, but resist the urge to mock everything. The tests that most closely mirror production conditions are the tests that catch production bugs.