API Test Automation

You add a new field to your API response and forget to update the mobile client’s type definitions. The web app handles it gracefully because it ignores unknown fields. The iOS app crashes because its strict decoder rejects the unexpected property. Three different consumers, three different expectations, and no contract tests to catch the mismatch. API testing is the glue that holds distributed systems together.

What You’ll Walk Away With

Comprehensive REST API test generation from OpenAPI specs or route analysis
GraphQL query and mutation testing with schema validation
Contract testing patterns that prevent consumer-provider drift
Authentication and authorization testing for every endpoint
AI prompts for testing error handling, edge cases, and rate limiting

REST API Test Generation

@src/routes/ @src/schemas/
Generate API tests for all endpoints in our Express application:

For each route file in /src/routes/:
1. Read the route definitions and Zod validation schemas
2. Generate tests for:
   - Valid request (200 response with correct shape)
   - Missing required fields (400 with validation errors)
   - Invalid field types (400 with specific error messages)
   - Authentication required (401 without token)
   - Authorization check (403 with wrong role)
   - Resource not found (404 with appropriate message)

Use supertest for HTTP assertions.
Use our test factories for request body generation.
Follow patterns in @tests/api/auth.api.test.ts
Save to /tests/api/{route-name}.api.test.ts

claude "Generate comprehensive API tests for our Express application:

1. Discover all routes: scan /src/routes/ for Express router definitions
2. For each endpoint (method + path), generate:
   - Happy path test with valid data
   - Validation failure tests (one per required field)
   - Auth tests (no token, expired token, wrong role)
   - 404 test for non-existent resources
   - Duplicate/conflict tests where applicable (409)

3. Create test infrastructure:
   - /tests/api/helpers/request.ts (authenticated request helpers)
   - /tests/api/helpers/seed.ts (database seeding for API tests)

4. Run all API tests against a test server
5. Fix any failures

Use supertest + Jest. Save to /tests/api/"

Generate API test coverage for all endpoints:
1. Discover routes from the application code
2. Generate tests for success, validation, auth, and error cases
3. Set up test database seeding
4. Run tests and fix failures
5. Create PR with the test suite and coverage report

Copy-paste prompt for thorough endpoint testing:

Generate exhaustive API tests for POST /api/orders:

Request body: { items: [{productId: string, quantity: number}], shippingAddress: Address, paymentMethodId: string }

Test categories:

1. Successful creation:
   - Single item order (verify response shape, 201 status)
   - Multi-item order (verify total calculation)
   - Verify the order appears in GET /api/orders after creation

2. Validation failures (400):
   - Empty items array
   - Item with quantity 0 or negative
   - Item with non-existent productId
   - Missing shipping address fields
   - Invalid payment method ID format

3. Business logic errors:
   - Out of stock product (409 with stock info)
   - Payment method expired (422 with user-friendly message)
   - Order total exceeds maximum (422)
   - Duplicate idempotency key (200 returning original order)

4. Authentication/Authorization:
   - No auth token (401)
   - Expired token (401)
   - User creating order for another user (403)

5. Edge cases:
   - Maximum items per order (boundary test)
   - Unicode characters in shipping address
   - Concurrent orders depleting the same stock

Include assertions for response headers: Content-Type, rate limit headers, cache-control.

GraphQL Testing

Copy-paste prompt for GraphQL test generation:

Generate tests for our GraphQL API:

1. Query tests:
   - users query with pagination (first, after cursor)
   - user(id) query with all fields
   - user(id) with nested relations (orders, preferences)
   - Query with field selection (verify only requested fields returned)
   - Query complexity limit (deeply nested query should be rejected)

2. Mutation tests:
   - createUser with valid input
   - createUser with validation errors (verify error extensions)
   - updateUser with partial fields
   - deleteUser and verify cascade behavior

3. Subscription tests (if applicable):
   - Subscribe to orderStatusChanged
   - Verify events are received when order status updates
   - Verify subscription respects authorization

4. Error handling:
   - Invalid query syntax (verify helpful error message)
   - Query for non-existent fields (introspection disabled in production)
   - Mutation with invalid variable types
   - Rate limiting on expensive queries

Use graphql-request for the test client.
Save to /tests/api/graphql/

Contract Testing

Ensuring Consumer-Provider Compatibility

Copy-paste prompt for contract test setup:

Set up consumer-driven contract testing between our services:

Provider: order-service (Express REST API)
Consumers: web-app (React), mobile-app (React Native), admin-dashboard (Next.js)

1. Create provider verification tests:
   - Load pact files from each consumer
   - Set up provider states (database seeding for each scenario)
   - Verify the provider satisfies all consumer contracts
   - Save to /tests/contracts/provider-verification.test.ts

2. Create consumer contract for the web-app:
   - Define expectations for GET /api/orders (list with pagination)
   - Define expectations for POST /api/orders (create)
   - Define expectations for GET /api/orders/:id (detail)
   - Define expectations for error responses (400, 404, 500)
   - Save to /tests/contracts/web-consumer.pact.test.ts

3. CI integration:
   - Consumer tests run in consumer's CI
   - Publish pact files to Pact broker
   - Provider verification runs in provider's CI
   - Block deployment if any contract is broken

Use Pact.js v12+ with the v4 specification.

API Response Validation

Copy-paste prompt for response schema validation:

Create response schema validation tests for our API:

1. Generate JSON Schema (or Zod schema) from each endpoint's TypeScript response type
2. For every API test, add schema validation:
   - Response body matches the expected schema exactly
   - No extra fields that are not in the schema (strict validation)
   - Date fields are in ISO 8601 format
   - IDs are valid UUIDs
   - Enum fields contain only valid values
   - Nested objects follow their schemas recursively

3. Create a test helper: validateResponse(response, schema) that:
   - Validates the body against the schema
   - Checks Content-Type header
   - Checks for required headers (pagination, rate-limit)
   - Provides clear error messages on failure

4. Generate a compatibility report:
   - Which endpoints have matching schemas between API and client types?
   - Which have drifted?

Save the schemas to /tests/api/schemas/
Save the helper to /tests/api/helpers/validate-response.ts

When This Breaks

“API tests are brittle because they depend on database state.” Use database transactions that roll back after each test, or seed specific data for each test in a beforeEach hook. Never share database state between test files.

“Contract tests fail because the provider changed intentionally.” This is working as designed. The contract test caught a breaking change before it reached consumers. Update the consumer contracts, notify consumer teams, and verify they can handle the change before deploying the provider.

“Tests pass but the API behaves differently in production.” Check for environment-specific behavior: feature flags, rate limits, caching, middleware that runs only in production. Your test environment should mirror production configuration as closely as possible.

“GraphQL tests are hard to maintain as the schema evolves.” Generate tests from the schema itself. When the schema changes, regenerate the tests. Keep a separate layer of business logic tests that test behavior independent of schema structure.

What’s Next

Integration Testing Test the full service stack, not just the API layer.

Security Testing Security-focused API testing for vulnerabilities.

Performance Testing Load testing your API endpoints under stress.