42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# 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.
|