Тестирование: unit, integration и e2e

28 июня 2026

Тесты в шаблоне — не декорация. Они покрывают критичные потоки: валидацию auth, парсинг форм, skip-логику аналитики, биллинг, админку и UI-компоненты billing/analytics. Цель — чтобы рефакторинг не ломал оплату и регистрацию незаметно.

Unit-тесты живут рядом с кодом: auth.schemas.test.ts, track.server.test.ts, skip.server.test.ts, admin.test.ts. Запуск — npm test (Vitest). Быстрые, без БД, идеальны для TDD при изменении чистых функций и схем Zod.

Component-тесты в tests/component используют @testing-library/react и Vitest. Примеры: AgentUsageMeter, AgentUsageHistoryTable, AnalyticsDashboard. Проверяют рендер при разных props, тексты, состояния загрузки — без реального браузера.

Integration-тесты в tests/integration поднимают настоящие loaders и actions с тестовой PostgreSQL. admin-users.integration.test.ts проверяет доступ к /admin/users: обычный пользователь получает отказ, админ — список. Такие тесты ловят ошибки в цепочке auth + DB + route.

Seed-данные в tests/helpers/seed.ts создают пользователей, подписки и события аналитики с предсказуемыми id. Используйте их вместо хардкода в каждом тесте — при смене схемы правите один файл.

E2E на Playwright имитирует пользователя в браузере. usage-billing.spec.ts проходит регистрацию, страницу billing, взаимодействие с тарифами. Конфигурация в playwright.config.ts: baseURL, timeout, retries в CI, screenshot on failure.

Локальный запуск e2e: npm run db:push, npm run dev в одном терминале, npm run test:e2e в другом. В CI webServer в playwright.config автоматически стартует dev-сервер — локально можно так же, чтобы не забыть поднять сервер.

Команда npm run ci — полный прогон: eslint, tsc --noEmit, vitest unit+integration. Запускайте перед каждым PR. GitHub Actions workflow в .github/workflows/ci.yml дублирует это на каждый push.

E2E в CI требуют PostgreSQL service container и переменные окружения из secrets. Не коммитьте .env с реальными ключами YooKassa или SMTP. Для e2e checkout можно мокать webhook или использовать test shop.

Что тестировать при добавлении фичи: сначала unit для чистой логики, потом integration если есть DB/API, e2e только для критичного user journey. Не нужен e2e на каждую кнопку — они дорогие и хрупкие.

При flaky e2e проверьте: race conditions (await expect с timeout), состояние БД между тестами (изоляция через уникальные email), параллельный запуск (workers в CI). Playwright trace при падении — ваш лучший друг.

Coverage не гонится за 100%. Шаблон фокусируется на regression-тестах для бизнес-критичных путей. Добавляйте тест, когда чините баг — чтобы он не вернулся.