Тестирование: Jest, Playwright, Cypress, k6, Lighthouse

Баг, найденный в юнит-тесте, стоит минуту исправления. Тот же баг в продакшене — часы инцидента, компенсации клиентам, потеря доверия. Это не абстрактный тезис: на проекте интернет-магазина баг в расчёте скидки прошёл ручное тестирование, попал в прод и за 4 часа обработал 37 заказов по нулевой цене. Автотест на граничные случаи расчёта стоял бы в CI и поймал его при первом же push.

Jest и юнит-тестирование: где это работает, а где нет

Jest — стандарт для JavaScript/TypeScript. Но юнит-тесты имеет смысл писать только там, где есть изолированная логика: функции трансформации данных, валидаторы, бизнес-правила, утилиты.

Тестировать React-компоненты через Jest + Testing Library правильно для поведенческих тестов: «кнопка появляется после загрузки данных», «форма показывает ошибку при пустом email». Снепшот-тесты (toMatchSnapshot) — ловушка: они ломаются при любом изменении вёрстки и превращаются в шум, который разработчики обновляют не глядя.

Покрытие кода (code coverage) — плохая метрика качества. 80% coverage можно получить тестами, которые ничего не проверяют. Coverage показывает, что код выполнился, не то, что он работает правильно.

Vitest как альтернатива Jest для Vite-проектов: в 10–20 раз быстрее за счёт нативного ES modules без трансформации через Babel. Для монорепозиториев с тысячами тестов разница в скорости ощутима.

Playwright: E2E тестирование, которое работает

Cypress долгое время был стандартом E2E, но Playwright обошёл его по ключевым параметрам: нативная поддержка multi-tab, multi-origin, iframe тестирования; параллельное выполнение на уровне тестов (не только файлов); WebKit, Firefox, Chromium из коробки; нет iframe для приложения — тесты работают в реальном браузере.

Playwright codegen записывает действия и генерирует тест — хорошая точка старта, но сгенерированный код нужно рефакторить. Локаторы по text content хрупки: getByRole('button', { name: 'Оформить заказ' }) — устойчивее, чем locator('.btn-primary').

Page Object Model — стандарт организации E2E тестов. Каждая страница — отдельный класс с методами вместо прямых локаторов в тестах. Когда кнопка переехала из хедера в сайдбар — меняем в одном месте, не ищем по всем тестам.

Типичная проблема — flaky tests. Тест иногда падает, иногда проходит. Причины: race condition между запросом и рендером, анимации без ожидания завершения, зависимость от внешних API. Решение: page.waitForResponse() вместо page.waitForTimeout(), мокирование внешних API через page.route().

// Плохо
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Хорошо
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Нагрузочное тестирование с k6

k6 — инструмент для нагрузочного тестирования с JavaScript API. Сценарии пишутся как код, версионируются в git, запускаются в CI.

Три основных сценария нагрузки:

Spike test — резкий рост нагрузки: 0 → 1000 пользователей за 30 секунд. Имитирует запуск рекламной кампании или попадание в топ новостей. Показывает, как система ведёт себя при резком росте и умеет ли автоскейлинг отреагировать вовремя.

Soak test — стабильная нагрузка на 2–4 часа. Выявляет memory leaks, connection pool exhaustion, деградацию производительности со временем.

Stress test — нагрузка выше расчётной (150–200% от ожидаемого пика). Показывает точку отказа и graceful degradation.

Пороговые значения в k6:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означает: 95% запросов отвечают быстрее 500ms. Если порог не выполняется — k6 завершается с кодом ошибки, CI-пайплайн падает.

Lighthouse и Core Web Vitals

Google использует Core Web Vitals в ранжировании. Lighthouse CLI в CI-пайплайне: при каждом деплое проверяем, что LCP < 2.5s, CLS < 0.1, INP < 200ms.

Реальные проблемы, которые Lighthouse находит:

• Hero image без width/height атрибутов: CLS 0.35 при загрузке (браузер сдвигает контент когда изображение загружается)
• JavaScript-бандл 2.1MB синхронно блокирует парсинг: INP 450ms
• Шрифты без font-display: swap: невидимый текст до загрузки шрифта (FOIT)
• Неоптимизированный hero image 4MB: LCP 8.2s

Lighthouse CI (lhci) сохраняет историю метрик и отправляет комментарий к PR с деградацией.

Пирамида тестирования в проекте

Процесс работы

Аудит текущего покрытия, определение критических user flows для E2E, настройка CI-пайплайна с параллельным выполнением тестов. Playwright тесты запускаем на sharded workers (4 шарды = 4x скорость). Нагрузочные тесты — отдельный stage, не блокируют feature деплои, запускаются перед релизами.

Сроки

Настройка полного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) с нуля: 2–4 недели. Покрытие E2E-тестами существующего проекта (20–30 сценариев): 3–6 недель. Нагрузочное тестирование с отчётом и рекомендациями: 1–2 недели.