Automatyzacja testów API

Dodajesz nowe pole do odpowiedzi API i zapominasz zaktualizować definicję typów klienta mobilnego. Aplikacja webowa radzi sobie elegancko, bo ignoruje nieznane pola. Aplikacja iOS crashuje, bo jej ścisły decoder odrzuca niespodziewaną właściwość. Trzech różnych konsumentów, trzy różne oczekiwania i żadnych testów kontraktowych, które złapałyby niedopasowanie. Testowanie API to klej, który trzyma systemy rozproszone razem.

Czego się nauczysz

• Kompleksowe generowanie testów REST API ze specyfikacji OpenAPI lub analizy routów
• Testowanie zapytań i mutacji GraphQL z walidacją schematu
• Wzorce testowania kontraktowego zapobiegające dryfowi konsument-dostawca
• Testowanie uwierzytelniania i autoryzacji dla każdego endpointu
• Prompty AI do testowania obsługi błędów, edge case’ów i rate limitingu

Generowanie testów REST API

Cursor

@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 Code

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/"

Codex

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

Wskazówka

Prompt do skopiowania — dokładne testowanie endpointu:

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.

Testowanie GraphQL

Wskazówka

Prompt do skopiowania — generowanie testów GraphQL:

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/

Testowanie kontraktowe

Zapewnienie kompatybilności konsument-dostawca

Wskazówka

Prompt do skopiowania — konfiguracja testów kontraktowych:

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.

Walidacja odpowiedzi API

Wskazówka

Prompt do skopiowania — walidacja schematu odpowiedzi:

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

Gdy coś się zepsuje

“Testy API są kruche, bo zależą od stanu bazy danych.” Użyj transakcji bazodanowych z rollback po każdym teście lub seeduj konkretne dane dla każdego testu w hooku beforeEach. Nigdy nie współdziel stanu bazy danych między plikami testowymi.

“Testy kontraktowe failują, bo dostawca zmienił się celowo.” Tak powinno działać. Test kontraktowy złapał breaking change zanim dotarł do konsumentów. Zaktualizuj kontrakty konsumentów, powiadom zespoły konsumentów i zweryfikuj, że poradzą sobie ze zmianą przed wdrożeniem dostawcy.

“Testy przechodzą, ale API zachowuje się inaczej na produkcji.” Sprawdź zachowanie specyficzne dla środowiska: feature flagi, rate limity, cache’owanie, middleware działający tylko na produkcji. Twoje środowisko testowe powinno maksymalnie odzwierciedlać konfigurację produkcyjną.

“Testy GraphQL są trudne w utrzymaniu, gdy schemat ewoluuje.” Generuj testy z samego schematu. Gdy schemat się zmienia, przegeneruj testy. Utrzymuj oddzielną warstwę testów logiki biznesowej testujących zachowanie niezależnie od struktury schematu.

Co dalej

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.