Отладка упавших тестов в Playwright: trace viewer и дебаг

Отладка теста в Playwright — это процесс выяснения, почему тест упал: не нашёлся элемент, не дождался нужного состояния страницы, получил не то значение. Главный инструмент для этого — trace viewer: он записывает пошаговый снимок всего, что происходило во время теста (скриншоты каждого действия, сетевые запросы, консоль браузера, DOM-снапшоты), и позволяет прокрутить прогон теста назад после его завершения, а не просто читать текстовый лог с сообщением об ошибке.

// playwright.config.js
export default {
use: {
trace: 'on-first-retry',
},
};

trace: 'on-first-retry' — практичная настройка по умолчанию: трейс записывается только тогда, когда тест упал и Playwright повторяет попытку (retry), а не при каждом успешном прогоне. Это экономит место на диске и время, потому что трейсы для сотен успешных тестов не нужны — важен именно трейс упавшего теста. Другие варианты значения: 'on' (всегда), 'off' (никогда), 'retain-on-failure' (записывать всегда, но сохранять файл только при итоговом падении теста).

npx playwright show-trace trace.zip
Команда открывает записанный трейс в интерактивном интерфейсе trace viewer — временной шкале с каждым действием теста (клик, заполнение поля, переход по URL). Для каждого шага можно посмотреть скриншот страницы до и после действия, DOM в этот момент, все сетевые запросы, которые происходили параллельно, и консоль браузера. Это часто быстрее, чем пытаться воспроизвести падение локально заново — особенно если тест падает нестабильно (flaky) и не воспроизводится по требованию.

npx playwright test checkout.spec.js --debug
Флаг --debug запускает Playwright Inspector — тест выполняется в видимом (не headless) браузере с возможностью ставить точки останова, выполнять шаги по одному и пробовать локаторы прямо в интерфейсе инспектора, до того как вставлять их в код. Это удобно на этапе написания нового теста или локатора, а не после того, как тест уже упал на CI — trace viewer лучше подходит именно для разбора уже случившегося падения.

test('оформление заказа', async ({ page }) => {
await page.goto('/checkout');
await page.pause();
await page.getByRole('button', { name: 'Оплатить' }).click();
});

page.pause() останавливает выполнение теста в конкретной строке кода и открывает Playwright Inspector — удобно, когда проблема известна примерно, но непонятно, что именно происходит на странице в этот момент. В отличие от --debug, который ставит паузу перед первым действием теста, page.pause() позволяет точно указать место в коде, где нужна остановка, не листая весь тест по шагам с самого начала.

// playwright.config.js
export default {
use: {
screenshot: 'only-on-failure',
video: 'retain-on-failure',
},
};

Помимо полного трейса, можно настроить более лёгкие артефакты: скриншот в момент падения теста и видеозапись всего прогона. only-on-failure и retain-on-failure сохраняют эти файлы только для упавших тестов, не раздувая отчёт для сотен успешных прогонов. На CI, где нет возможности посмотреть на тест вживую, это первое, на что стоит взглянуть при разборе падения, прежде чем открывать полный трейс.

Чем trace viewer отличается от простого скриншота при падении? Скриншот — это один статичный кадр в момент падения. Trace viewer — это пошаговая запись всего прогона теста: каждое действие, DOM в этот момент, сетевые запросы и консоль, которые можно прокручивать вперёд и назад, как запись экрана с возможностью инспектировать каждый шаг.
Когда использовать --debug, а когда trace viewer? --debug удобен во время написания теста, когда нужно пошагово проверить логику или подобрать локатор в реальном времени. Trace viewer лучше подходит для разбора теста, который уже упал (особенно на CI), потому что не требует повторного запуска — весь прогон уже записан.
Почему trace нельзя записывать всегда, для всех тестов? Технически можно (trace: 'on'), но трейсы занимают заметное место на диске и время на запись, особенно для больших сьютов с сотнями тестов. 'on-first-retry' — компромисс, который сохраняет трейс только там, где он реально понадобится — для упавших тестов.
Как разобраться с нестабильным (flaky) тестом, который падает не всегда? Именно для таких случаев on-first-retry особенно полезен: трейс запишется автоматически в момент падения, даже если проблема не воспроизводится намеренно — не нужно ловить конкретный флаки-прогон вручную.

Разобрать реальный flaky-тест по записанному trace — навык, который нарабатывается только на практике. Бесплатный тренажёр Playwright Arena — для основ. Для разбора отладки на реальном проекте с ментором — курс «Автотестирование JS/TS + Playwright» в Quality Academy.

-------

Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena