Отчёты

Урок: Отчёты в Playwright

Введение

Представь ситуацию: ты запустил автотесты, они отработали, и в консоли просто написано — «3 теста упало». Всё. Никаких деталей.

Что делать дальше? Где именно ошибка? Что происходило в тесте? Как выглядела страница в момент падения?

Без отчётов ты фактически остаёшься «в темноте».

Теперь представь другой сценарий: после запуска тестов у тебя открывается страница, где видно:

  • какие тесты прошли, а какие упали;
  • на каком шаге произошла ошибка;
  • скриншоты, видео и логи;
  • подробный таймлайн выполнения.

Вот это и есть отчёты — инструмент, который превращает тесты из «чёрного ящика» в прозрачный и понятный процесс.

В Playwright отчёты — это не дополнительная опция, а важная часть работы с тестами.

Официальные материалы: Reporters, Trace Viewer, опции записи в конфиге — Configuration (use). Аннотации и вложения в отчёте — Annotations.

Что такое отчёты и зачем они нужны

Отчёт — это результат выполнения тестов в удобном для анализа виде.

После запуска тестов Playwright собирает информацию:

  • какие тесты запускались;
  • какие прошли, какие нет;
  • сколько времени занял каждый тест;
  • какие ошибки возникли;
  • дополнительные артефакты (скриншоты, видео, trace).

Главная задача отчёта — помочь тебе быстро понять:

  • что сломалось;
  • где именно;
  • почему это произошло.

Без отчётов тесты теряют значительную часть своей ценности, потому что диагностика становится сложной и долгой.

Репортёры и HTML-отчёт

У Playwright Test есть несколько встроенных репортёров; самый наглядный для разбора падений — HTML. В терминале по умолчанию при локальном запуске чаще используется list (построчный вывод), а в CI по умолчанию — сжатый dot. HTML нужно явно добавить в конфиг или передать в CLI — см. Reporters.

Выбор репортёра из командной строки:

npx playwright test --reporter=html

В конфигурации:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: 'html',
});

Несколько репортёров сразу (удобно: консоль + файл):

export default defineConfig({
  reporter: [
    ['list'],
    ['html', { open: 'never' }],
  ],
});

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

export default defineConfig({
  reporter: process.env.CI ? 'dot' : 'list',
});

HTML-репортёр: папка, автозапуск браузера

По умолчанию отчёт пишется в каталог playwright-report. Путь можно задать опцией outputFolder или переменной окружения PLAYWRIGHT_HTML_OUTPUT_DIR.

Поведение «открыть отчёт в браузере» настраивается через open: 'always', 'never' или 'on-failure' (значение по умолчанию — при падениях отчёт откроется сам). То же можно задать через PLAYWRIGHT_HTML_OPEN. Для хоста и порта сервера отчёта — host и port (или env PLAYWRIGHT_HTML_HOST / PLAYWRIGHT_HTML_PORT). Полная таблица опций — в HTML reporter.

Для загрузки отчёта и вложений на разные URL в CI есть attachmentsBaseURL.

Запуск и просмотр отчёта

После выполнения тестов можно открыть последний HTML-отчёт:

npx playwright show-report

Если в конфиге указан свой каталог:

npx playwright show-report my-report

Что происходит

  • Playwright поднимает локальный просмотрщик и открывает сохранённый отчёт;
  • в интерфейсе видны тесты, ошибки, вложения (скриншоты, видео, trace и т.д.).

Что есть внутри HTML-отчёта

Когда ты открываешь отчёт, ты видишь структуру:

  • список тестов;
  • статус (passed / failed);
  • длительность;
  • ошибки.

Но самое интересное — это детали теста.

Внутри одного теста

Ты можешь увидеть:

  • шаги выполнения;
  • скриншоты;
  • видео;
  • trace (если включён);
  • текст ошибки и stack trace.

Это превращает дебаг из угадывания в понятный процесс.

Добавление скриншотов в отчёты

Отчёты становятся особенно полезными, когда в них есть визуальные данные.

Пример сохранения файла на диск

test('пример со скриншотом', async ({ page }) => {
  await page.goto('https://example.com');

  await page.screenshot({ path: 'screenshot.png' });
});

Что происходит

  • page.screenshot() делает снимок страницы;
  • файл сохраняется по указанному пути.

Чтобы файл появился как вложение в HTML-отчёте, удобнее прикрепить его через test.info().attach (см. testInfo.attach) — тогда его увидят и коллеги, открыв отчёт из CI.

Автоматические скриншоты при ошибках

Playwright умеет прикреплять скриншоты к результату теста без ручного path.

Пример конфигурации

export default defineConfig({
  use: {
    screenshot: 'only-on-failure',
  },
});

Объяснение

По Recording options для screenshot доступны режимы 'off', 'on' и 'only-on-failure' — последний экономит место и шум: снимок делается только при падении теста.

Скриншоты, видео и trace попадают в каталог результатов прогона (часто test-results рядом с проектом).

Видео в отчётах

Иногда скриншота недостаточно — нужно увидеть процесс.

Пример настройки

export default defineConfig({
  use: {
    video: 'retain-on-failure',
  },
});

Что означает

Для video в документации перечислены 'off', 'on', 'retain-on-failure' и 'on-first-retry' — см. testOptions.video. Режим retain-on-failure оставляет запись, если тест упал; on-first-retry выгоден вместе с ретраями на CI.

Trace — самый мощный инструмент отчётов

Trace — это подробная запись выполнения теста (действия, DOM-снимки, сеть, консоль и др.) — см. Trace Viewer.

Включение

export default defineConfig({
  retries: 1,
  use: {
    trace: 'on-first-retry',
  },
});

Для режима on-first-retry в документации рекомендуют задать retries: ≥ 1: trace пишется при первом повторе после падения — так балансируют нагрузку на CI и полезность артефакта.

Если ретраев нет, но нужен trace только на падениях, подойдёт trace: 'retain-on-failure'.

Доступные значения trace: 'off', 'on', 'retain-on-failure', 'on-first-retry', 'on-all-retries' — полный список и нюансы в testOptions.trace.

Локально на время отладки можно записать trace для всех тестов:

npx playwright test --trace on

В UI Mode trace для прогонов собирается удобнее «из коробки» — см. UI Mode.

Как открыть

npx playwright show-trace path/to/trace.zip

Можно открыть trace по URL (удобно из CI): npx playwright show-trace https://example.com/trace.zip. Статический просмотрщик без отправки данных наружу — trace.playwright.dev (drag-and-drop файла или параметр ?trace=... к загруженному архиву; возможны ограничения CORS).

Что ты увидишь

В Trace Viewer есть вкладки Actions, Screenshots (лента кадров), Snapshots DOM (before / action / after), Source, Call, Log, Errors, Console, Network, Metadata, Attachments — см. раздел Trace Viewer features.

После прогона с --trace on trace можно открыть и из HTML-отчёта по иконке trace.

Другие типы отчётов

Помимо HTML, Playwright поддерживает и другие форматы.

Пример

export default defineConfig({
  reporter: [['list'], ['json', { outputFile: 'report.json' }]],
});

Объяснение

  • list, line, dot — вывод в терминал с разной детализацией; на CI по умолчанию dot — List / Line / Dot;
  • json / junit — машиночитаемые файлы для пайплайнов и отчётности в Jenkins, GitLab и т.п.;
  • github — аннотации к падениям в GitHub Actions (GitHub reporter);
  • blob — промежуточный «сырой» отчёт для слияния шардов и последующей сборки HTML — Blob reporter, Sharding;
  • можно комбинировать несколько репортёров и задавать свой класс — Custom reporters, API Reporter.

Где это используется

  • интеграция с CI/CD;
  • отправка данных в системы аналитики;
  • построение кастомных дашбордов.

Практический смысл отчётов

В реальной работе отчёты:

  • ускоряют поиск ошибок;
  • позволяют другим членам команды понимать, что произошло;
  • используются в CI (например, GitHub Actions, GitLab CI);
  • помогают анализировать стабильность тестов.

Особенно важно это в больших проектах, где тестов сотни или тысячи.

Без отчётов автотесты превращаются в «чёрный ящик», а с отчётами — в инструмент диагностики.

Итоговое понимание

Отчёты — это не просто «лог после тестов», а главный инструмент понимания того, как работают твои тесты.

Они превращают результат выполнения из сухого «прошёл / упал» в подробную картину: что происходило, где сломалось и почему.

Главная идея в том, что тесты — это не только проверка, но и источник информации. И отчёты — это способ эту информацию увидеть и использовать.

Чем осознаннее выбраны репортёры и запись артефактов (screenshot, video, trace в use, сочетание HTML/json/junit/github/blob в reporter), тем быстрее диагностика — см. Reporters и Trace Viewer. От этого напрямую зависит надёжность автоматизации в команде и на CI.