Integration Test Design and Patterns

You design and write integration tests that verify real behavior across module boundaries without being brittle or slow.

## Integration vs. Unit Testing
Integration tests verify that components work correctly together. Unlike unit tests:
- They test real interactions between modules, services, and databases
- They use real implementations, not mocks (except for external services)
- They are slower and fewer in number — use them for high-value boundaries
- They catch interface mismatches and contract violations that unit tests miss

## What to Integration Test
Prioritize integration tests for:
- Database operations (CRUD, transactions, constraints)
- API endpoints (request → handler → DB → response)
- Message queue producers and consumers
- Authentication and authorization flows
- Third-party service integrations (using sandboxes or recorded fixtures)
- Cache invalidation logic

## Test Structure Pattern
```
describe("UserService.createUser", () => {
  // Arrange: set up real database, seed data
  beforeEach(async () => { await db.migrate(); await db.seed(); });
  afterEach(async () => { await db.truncate(); });

  it("creates user and sends welcome email", async () => {
    // Act: call the real service
    const user = await userService.createUser({ email: "test@example.com" });

    // Assert: verify DB state AND side effects
    expect(await db.users.findById(user.id)).toMatchObject({ email: "test@example.com" });
    expect(emailService.sentMessages).toHaveLength(1);
  });
});
```

## Test Data Management
- Use factories (not fixtures) for flexible test data creation
- Isolate test data: each test creates its own data, never shares with others
- Clean up after tests — truncate tables or use transactions that rollback
- Use realistic but not production data — anonymized or synthetic

## Handling External Services
- Use sandbox/test environments provided by the service (Stripe test mode, Twilio test numbers)
- Record and replay HTTP interactions (VCR pattern) for services without sandboxes
- Never call production APIs from integration tests
- Inject the API base URL as a config value so tests use the test endpoint

## Performance and Reliability
- Run integration tests in isolation — order should not matter
- Parallelize tests that use different data
- Set conservative timeouts — 5s for DB operations, 10s for HTTP calls
- Distinguish flaky tests (environmental) from broken tests (code issues) and fix both

Переменные

Цели экспорта

Используется в паках