E2E-тесты в CI: запуск, ускорение и разбор падений

← назад к разделу

E2E-тесты не защищают от регрессий, если их гонять «когда вспомнил» вручную. Они работают только в связке с конвейером: каждое изменение → автоматический прогон → результат виден команде. Но у сквозных тестов есть особенность: они медленные. Поэтому в CI важны две вещи — уложиться по времени и дать разбираемый отчёт о падении, чтобы чинить без воспроизведения локально.

Как устроен запуск

Playwright в CI работает без окна браузера (headless-режим). Браузеры нужно установить заранее — это делается один раз в начале шага.

Минимальный пайплайн выглядит так:

- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test

Перед запуском тестов должно работать само приложение. Можно поднять его вручную в пайплайне, а можно дать Playwright сделать это самому через webServer в конфиге — он запустит приложение и дождётся готовности перед первым тестом:

// playwright.config.ts
webServer: {
  command: "npm run start",
  url: "http://localhost:3000",
  reuseExistingServer: !process.env.CI,
},

В CI переменная CI всегда выставлена, поэтому каждый прогон поднимает свежий сервер.

Проблема скорости — и как её решают

E2E-тест открывает браузер, кликает, ждёт ответа сервера. Один тест — несколько секунд. Сто тестов — минуты. По мере роста проекта набор тестов растёт, и суммарное время пайплайна становится неприемлемым.

Два инструмента решают это:

Параллельные воркеры — Playwright по умолчанию запускает тесты параллельно в нескольких воркерах на одной машине. Количество воркеров настраивается в конфиге или флагом --workers.

Sharding — разбивка набора между несколькими машинами. Каждая машина берёт свою часть и гоняет её параллельно с остальными:

strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}/4

Четыре раннера вместо одного — набор завершается примерно вчетверо быстрее. Число частей выбирают исходя из размера набора и желаемого времени.

Почему падения в CI так тяжело чинить

Классическая ситуация: тест прошёл локально, упал в CI. Воспроизвести не получается — окружение другое, данные другие, гонки таймингов. Без записи прогона приходится гадать.

Playwright решает это через артефакты падения. Три инструмента:

Trace — полная запись прогона: каждый шаг, состояние DOM в момент выполнения, сетевые запросы, консоль. Открывается в Trace Viewer — можно промотать к любому шагу и посмотреть, что было на странице. Обычно включают on-first-retry: первый провал идёт без trace, если тест падает снова — запись включается.

Скриншот — снимок страницы в момент падения.

Видео — запись всего прогона теста.

use: {
  trace: "on-first-retry",
  screenshot: "only-on-failure",
  video: "retain-on-failure",
},

Эти файлы сохраняются как артефакты CI-шага — их можно скачать и изучить после прогона.

HTML-отчёт

Playwright генерирует HTML-отчёт: список тестов, время каждого, статус, ссылки на артефакты падений. Отчёт публикуют как артефакт CI — и каждый в команде видит картину прогона без того, чтобы лезть в сырые логи.

Зелёный статус — всё прошло. Красный — кликнуть на упавший тест, открыть trace, разобраться.

Когда гонять и что именно

Не все тесты нужны на каждый коммит. E2E — дорогие, и гонять тяжёлый полный набор на каждое изменение замедляет разработку. Практичная стратегия:

• На каждый PR — только критические пути: вход, главный сценарий, оплата (если есть). Быстрый набор, который не даёт пропустить поломку главного.
• Перед релизом или по расписанию — полный набор, включая длинные и редкие сценарии.

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

Коротко

• Playwright в CI работает headless; браузеры устанавливают через npx playwright install --with-deps.
• webServer в конфиге поднимает приложение перед прогоном — удобно для CI без ручных шагов.
• Воркеры распараллеливают тесты на одной машине, sharding — между несколькими раннерами.
• Trace (on-first-retry), скриншот и видео при падении делают разбор возможным без локального воспроизведения.
• HTML-отчёт показывает результаты и артефакты всей команде.
• Критические пути — на каждый PR; полный набор — перед релизом или по расписанию.

Что почитать дальше

• Настройка Playwright — конфиг, baseURL и webServer подробнее.
• Flaky-тесты — почему тесты нестабильны в CI и как это лечить.
• Принципы конвейера доставки — место e2e в общей схеме CI/CD.