Mocking strategy documented

Unit tests that call real external services — databases, APIs, email providers — are not unit tests: they are slow, flaky, and environment-dependent. ISO 25010:2011 §6.5.5 requires that tests produce deterministic results. Without consistent mocking, a failing test might be a real bug, a network blip, a rate limit hit, or a service outage — and distinguishing between them wastes engineering time. Real API calls in tests also risk leaking test data to production systems or incurring costs from development runs.

Adopt a consistent mocking strategy. For HTTP calls, msw (Mock Service Worker) intercepts at the network layer and works with any fetch-based code:

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

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Test User' })
  }),
  http.post('/api/users', () => {
    return HttpResponse.json({ id: 'new-id' }, { status: 201 })
  }),
]

For module-level mocking in Vitest:

vi.mock('@/lib/email', () => ({
  sendEmail: vi.fn().mockResolvedValue({ success: true }),
}))

Store reusable fixture data in tests/fixtures/ as typed constants or JSON files.