# Testing Blueprints

The template ships with full Vitest suites under `__tests__/`. They currently reference the `@/` module alias from a Next.js project. Replace those imports with your actual modules as you build the app. Use this guide to adapt the patterns.

## API routes
- File: `__tests__/api/*`
- Focus: HTTP status codes, query parsing, pagination, error handling.
- Mocks: database adapters, third-party SDKs, feature flags.
- Tips: assert on both response body and the parameters passed into mocked dependencies.

## Components
- File: `__tests__/components/*`
- Focus: accessibility, copy, conditional rendering, navigation flows.
- Mocks: Next.js router, contexts, external hooks.
- Tips: render minimal UI tree, interact with `@testing-library/react` utilities, assert on semantics not implementation.

## Hooks
- File: `__tests__/hooks/*`
- Focus: lifecycle, browser APIs (scroll, resize), async behaviour.
- Mocks: `window`, `document`, timers, intersection observers.
- Tips: wrap `act` around updates, reset mocks between tests, include teardown coverage.

## Flags & configuration
- File: `__tests__/flags/*`
- Focus: toggling features on/off, server-side overrides, fallbacks.
- Mocks: flag evaluation client, configuration store.
- Tips: include “flag service offline” scenarios to enforce safe defaults.

## Libraries
- File: `__tests__/lib/*`
- Focus: data migration guards, validation, persistence abstractions.
- Mocks: filesystem, database clients, clock.
- Tips: write table-driven tests so new edge cases are easy to add.

### Making them yours
1. Rename folders to match real domains (`users`, `billing`, `cms`).
2. Swap module imports from `@/lib/...` to wherever your implementation lives.
3. Keep the error-handling tests, even if you simplify the happy path—they are cheap insurance.
4. Run `pnpm test` (or your equivalent) often; treat failures as documentation gaps.

These suites double as onboarding material. New contributors can read the tests to understand intent before diving into production code.