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

Запуск в пайплайне

В CI Playwright гоняется headless, с предустановкой браузеров. Шаг сводится к установке зависимостей, браузеров и запуску набора.

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

Перед тестами поднимают приложение (или используют развёрнутый стенд) и дают Playwright его baseURL (из конфига). webServer в конфиге умеет поднимать приложение сам перед прогоном — удобно для CI.

Параллелизм и sharding

E2E долгие, поэтому их распараллеливают. Playwright прогоняет тесты параллельно в воркерах на одной машине; для больших наборов добавляют sharding — разбивку набора на части по нескольким машинам CI.

- run: npx playwright test --shard=${{ matrix.shard }}/4

Четыре shard'а — набор гоняется вчетверо быстрее на четырёх раннерах. Это то, что удерживает e2e в разумном времени по мере роста.

Traces, скриншоты, видео

Главная боль e2e — «упал в CI, локально не воспроизводится». Лечится артефактами падения. Trace (включён on-first-retry) — это запись прогона: каждый шаг, состояние DOM, сеть, — открывается в просмотрщике и показывает, что именно пошло не так. Скриншот и видео при падении дополняют картину.

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

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

Отчёты

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

Когда гонять

E2E дорогие, поэтому их запуск дозируют:

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

Гонять весь тяжёлый набор на каждый коммит — тормозить разработку; не гонять вовсе — терять смысл e2e. Баланс — критические на PR, полный — реже.

Где это в UCP

E2E в CI — это автоматизация последнего рубежа: тесты гоняются сами, sharding держит их в разумном времени, traces делают падения разбираемыми, дозировка балансирует уверенность и скорость. Это часть конвейера доставки — quality gate перед продом, как backend-тесты и сборка. Для продукт-инженера это автоматическая гарантия, что собранный продукт работает для пользователя на каждом изменении — и этим замыкается специализация e2e: от выбора, что покрывать, до запуска в конвейере.