В больших проектах я применяю многоуровневую стратегию тестирования, основанную на принципах пирамиды тестирования и рискоориентированного подхода. Каждый тип тестов — unit, integration, e2e, contract — выполняет свою задачу и применяется там, где наиболее эффективен с точки зрения скорости, стабильности, покрытия бизнес-логики и затрат на поддержку.

Общий подход

Стратегия строится как пирамида (в классическом варианте) или ромб (в более современных системах), где:

• Юнит-тестов больше всего — они быстрые, дешёвые и проверяют логику изолированно.

• Интеграционные тесты — покрывают связки компонентов.

• Контрактные тесты — особенно актуальны при микросервисной архитектуре или раздельных фронт/бэк командах.

• E2E-тесты — немного, но они критичны для проверки основных пользовательских сценариев.

1. Unit-тесты (юнит-тестирование)

Цель: Проверка логики отдельных функций, хуков, компонентов без сторонних зависимостей.

Примеры юнит-тестов:

• Проверка бизнес-логики (например, функция расчёта скидки).

• Тестирование кастомных хуков (usePagination, useDebounce).

• UI-компоненты без сайд-эффектов (Button, Badge, Loader).

Инструменты:

• Jest — как основной тест-раннер.

• @testing-library/react — для тестирования компонентов.

• msw (Mock Service Worker) — мокаем запросы.

• Vitest — в vite-проектах.

Особенности подхода:

• Максимальная изоляция: мокаются все внешние зависимости.

• Покрытие должно быть высоким, особенно для критичных функций.

• Используется snapshot-тестирование, но только там, где UI стабильный.

2. Integration-тесты (интеграционное тестирование)

Цель: Проверка совместной работы нескольких модулей или компонентов.

Примеры:

• Проверка формы: валидация, отправка, обработка результата.

• Компоненты с API-запросами: useQuery, useMutation.

• Проверка навигации между страницами (React Router, Next.js router).

Инструменты:

• Testing Library + Jest или Vitest.

• MSW для стабилизации API.

• React Query Test Utils — если используется React Query.

Принципы:

• Меньше мока, больше реалистичности.

• Тестируем взаимодействие компонентов, но без настоящего backend.

Проблемы и решения:

• Зависимость от сетевых запросов решается с помощью msw.

• Медленные тесты оптимизируются за счёт точечной мокации или дебаунсов.

3. Contract-тесты (контрактное тестирование)

Цель: Обеспечить согласованность интерфейсов между фронтендом и бэкендом, особенно при раздельной разработке.

Примеры:

• Проверка соответствия ответов API ожидаемым структурам.

• Использование OpenAPI, Swagger, GraphQL SDL как источник контрактов.

• Тестирование моделей запросов/ответов.

Инструменты:

• pact-js, Pactum, Dredd — для HTTP-контрактов.

• Zod, Yup, io-ts — для runtime-валидации схем.

• MSW + собственные схемы валидации.

Подходы:

• Используем схемы (OpenAPI/GraphQL) как единый источник истины.

• Тесты генерируются автоматически или вручную валидируют структуру ответа.

• Фронтенд CI падает, если схема не соответствует контракту.

Вариант: использование zod или yup для валидации API прямо внутри компонентов + генерация типов через openapi-typescript.

4. E2E-тесты (end-to-end)

Цель: Проверка ключевых пользовательских сценариев от начала до конца в реальной среде (или максимально приближённой).

Примеры сценариев:

• Регистрация → авторизация → профиль.

• Добавление товара в корзину → оформление заказа.

• Создание поста → проверка отображения.

Инструменты:

• Cypress — один из самых популярных.

• Playwright — более гибкий и быстрый, особенно для CI.

• TestCafe, Selenium — устаревающие, но иногда используются.

Особенности:

• Выполняются в браузере.

• Медленные, но дают уверенность, что всё работает на уровне UI/API.

• Используются для smoke-тестов, regression-тестов, nightly build.

Стратегии:

• Покрываются только критичные пользовательские потоки.

• E2E тесты работают на staging- или test-сервере.

• В CI запускаются в ночных сборках или по тегу (@smoke, @e2e).

Стабильность:
Тесты оборачиваются в retry и use data-testid вместо CSS/DOM-селекторов для стабильности.

CI/CD и автоматизация

Интеграция в pipeline:

• unit и integration — на каждый PR.

• contract — на каждый push в develop/main.

• e2e — по расписанию или на staging перед релизом.

Инструменты:

• GitHub Actions, GitLab CI, CircleCI.

• Code coverage отчёты (jest --coverage, nyc, codecov).

• Static analysis (eslint, typescript, depcheck) перед тестами.

Метрики, которые отслеживаются

• Test coverage (покрытие кода тестами): не самоцель, но помогает выявлять слепые зоны.

• Test flakiness (нестабильность тестов): фиксируется и устраняется, особенно в e2e.

• Время выполнения: юнит-тесты должны укладываться в 1–2 минуты.

• Процент ручного тестирования: стремление к автоматизации повторяемых действий.

Модульная организация тестов

• src/components/.../_tests_/... — для unit и component тестов.

• src/__integration__ — интеграционные сценарии.

• cypress/e2e/... или tests/e2e/... — e2e.

• tests/contracts/... — openapi или pact тесты.

Каждый тип теста имеет свой setup, свой раннер и свои правила.

Распространённые практики

• Factory функции (через @faker-js/faker, test-data-bot) — генерация мок-данных.

• Использование msw даже в e2e для отлова нестабильных API.

• Утилизация screen.debug() и logTestingPlaygroundURL() при отладке.

• Использование jest.spyOn для слежения за побочными эффектами (например, localStorage, cookies, console).

Такая стратегия позволяет масштабировать тестирование по мере роста команды и проекта, удерживать стабильность при большом количестве фич и ускорять выпуск новых версий без регрессий.