Playwright Trace Viewer: отлаживайте упавшие тесты как профессионал

Падение теста в CI которое не воспроизводится локально сложно отлаживать имея только стектрейс. Trace Viewer записывает каждое действие, сетевой запрос и DOM-снимок во время теста, и позволяет открыть воспроизведение временной шкалы в браузере после. Снимок Before на упавшем действии показывает что Playwright реально видел: какой элемент был подсвечен, перекрывал ли его оверлей, находился ли ещё в полёте API-ответ в момент клика.

Что такое Trace Viewer

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

Разница как между чтением стектрейса и просмотром записи.

Включение трейсов

По умолчанию трейсы отключены. Включи в playwright.config.ts:

use: {
  trace: 'on-first-retry',
},

Четыре опции:

| Значение | Когда использовать |

|----------|--------------------|

| 'off' | По умолчанию, трейсы не генерируются |

| 'on' | Каждый прогон, каждый тест. Удобно локально, слишком медленно для больших CI-сьютов |

| 'on-first-retry' | Только при ретрае теста. Лучший выбор для CI: минимальный оверхед, захватывает падения |

| 'retain-on-failure' | Сохраняет трейсы только для упавших тестов. Хороший баланс для локальной отладки |

Для CI стандартный выбор: 'on-first-retry'. Для локальной отладки конкретного теста переключи на 'on' временно.

Открытие трейса

После упавшего прогона Playwright создаёт zip-файлы внутри test-results/. Чтобы открыть:

npx playwright show-trace test-results/my-test-chromium/trace.zip

Или, если запускал тесты с HTML-репортёром: открой playwright-report/index.html и кликни иконку трейса рядом с упавшим тестом. Трейс откроется автоматически.

Чтение временной шкалы

Интерфейс Trace Viewer состоит из трёх панелей.

Временная шкала (сверху): горизонтальная полоса показывающая полную продолжительность теста. Каждое действие отмечено как сегмент. Клик по любому сегменту переходит к этому моменту. Список действий (слева): каждый шаг по порядку: page.goto, locator.click, expect, сетевые вызовы. У каждого есть продолжительность. Медленные действия сразу бросаются в глаза. Снимки (справа): состояние DOM на выбранном действии. Две вкладки: Before (как выглядела страница когда Playwright начал действие) и After (как выглядела когда действие завершилось).

Под снимками: вкладка Network (все HTTP-запросы в этот момент), вкладка Console (любой вывод console.log), вкладка Source (какая строка твоего теста вызвала это действие).

Рабочий процесс отладки падения

1. Найди упавшее действие в списке, оно отмечено красным.

2. Кликни по нему. Посмотри на снимок Before.

3. Спроси: элемент видим? Он задизейблен? Есть ли оверлей его перекрывающий?

4. Если элемент выглядит нормально а действие упало, проверь Network: был ли медленный API-вызов ещё в полёте?

5. Проверь Console: есть ли JavaScript-ошибки объясняющие состояние?

Большинство падений становятся очевидными в течение 30 секунд после открытия трейса. DOM-снимок показывает что Playwright реально видел, а это почти всегда отличается от того что ты предполагал.

Распространённые паттерны падений в трейсах

Проблемы с таймингом. В списке действий видно page.waitForURL или locator.waitFor завершившийся по таймауту. Снимок Before показывает что элемент ещё не существует. Решение: добавь явное ожидание элемента который сигнализирует о готовности, а не просто таймаут. Нарушения строгого режима. Использован локатор совпавший с несколькими элементами. Снимок Before покажет: наведи на подсвеченные элементы чтобы посчитать их. Состояние от предыдущего теста. Снимок Before первого действия показывает что ты уже залогинен, или toast-уведомление перекрывает кнопку. Тест предполагал чистое состояние. Решение: добавь правильную изоляцию тестов. Анимация или переход блокирует клик. Снимок Before показывает элемент, снимок After показывает что ничего не произошло. CSS-переход был в середине выполнения когда Playwright кликнул. Решение: жди завершения анимации или используй locator.click({ force: true }) для временной отладки (никогда в финальных тестах). Выбран не тот элемент. Снимок Before показывает что Playwright подсветил совсем другой элемент чем ты ожидал. Твой селектор совпадает с чем-то другим на странице. Исправь локатор.

Трейсы в CI

При запуске в GitHub Actions добавь шаг загрузки артефакта с трейсом:

- name: Run tests
  run: npx playwright test

- name: Upload traces
  if: failure()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-traces
    path: test-results/
    retention-days: 7

Скачай артефакт после упавшего прогона, распакуй и открой через npx playwright show-trace. Увидишь то же воспроизведение что и локально: состояние браузера CI-окружения в момент падения.

Трейсы, скриншоты и видео вместе

Playwright также умеет делать скриншоты при падении и полные видеозаписи прогона:

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

Используй все три для отладки сложных падений. Скриншот даёт статичное изображение; видео даёт полный прогон; трейс даёт полный прогон плюс каждое состояние DOM плюс сетевые вызовы. Они дополняют друг друга: скриншот пропускает что произошло за пять секунд до падения, в трейсе есть всё.

Для рутинного CI достаточно только трейсов. Видео добавляет значительный оверхед и обычно оправдано только для периодических падений которые не воспроизвести локально.

Когда трейсов недостаточно

Trace Viewer показывает состояние браузера. Состояние сервера он не показывает. Если тест падает потому что API вернул неожиданные данные, трейс покажет плохой ответ во вкладке Network, но не объяснит почему бэкенд его вернул.

Для таких падений совмещай данные трейса (чтобы увидеть каким был ответ) с логами бэкенда (чтобы понять почему). Трейс приводит к правильному вопросу; логи отвечают на него.