Алертинг при падении

Основы обработки ошибок и падений тестов

В автоматизированном тестировании важно не только проверять функциональность, но и фиксировать события падений тестов для последующего анализа. Playwright предоставляет встроенные механизмы для отслеживания ошибок, логирования и реагирования на исключительные ситуации. Алертинг при падении включает три ключевых аспекта: перехват исключений, сбор данных о состоянии приложения и уведомление команды о проблеме.

Перехват исключений

Playwright использует промисы и асинхронные функции, поэтому основным инструментом обработки ошибок является конструкция try...catch. Пример базовой структуры:

const { test, expect } = require('@playwright/test');

test('пример обработки падения', async ({ page }) => {
    try {
        await page.goto('https://example.com');
        await expect(page.locator('h1')).toHaveText('Заголовок');
    } catch (error) {
        console.error('Тест завершился с ошибкой:', error);
        throw error; // Обязательно пробрасывать ошибку дальше для корректного отчета
    }
});

Ключевые моменты:

  • Любое исключение, возникающее внутри try, фиксируется в catch.
  • Ошибка выводится в консоль для первичного анализа.
  • Проброс ошибки необходим, чтобы система тестирования зарегистрировала падение теста.

Сбор информации при падении

Для эффективного алертинга критично сохранять данные о состоянии тестируемого приложения. Playwright предоставляет средства для скриншотов, видео и логов сети.

Скриншоты:

await page.screenshot({ path: `screenshots/failure-${Date.now()}.png`, fullPage: true });

Видео:

В конфигурации тестов можно включить запись видео:

// playwright.config.js
module.exports = {
    use: {
        video: 'on',
    },
};

Видео автоматически сохраняется для всех падений тестов.

Логи сети:

page.on('requestfailed', request => {
    console.log(`Не удалось выполнить запрос: ${request.url()} - ${request.failure().errorText}`);
});

Таким образом можно фиксировать ошибки на уровне HTTP-запросов, что особенно важно для тестирования сложных SPA.

Настройка алертов и уведомлений

Сбор данных сам по себе не предупреждает команду о проблеме. Для полноценного алертинга используются внешние интеграции. Наиболее распространенные варианты: Slack, Email, системы мониторинга типа Sentry.

Пример отправки уведомления в Slack при падении теста:

const fetch = require('node-fetch');

async function sendSlackAlert(message) {
    await fetch('https://hooks.slack.com/services/TOKEN', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ text: message }),
    });
}

test('тест с алертом', async ({ page }) => {
    try {
        await page.goto('https://example.com');
        await expect(page.locator('h1')).toHaveText('Неверный заголовок');
    } catch (error) {
        await page.screenshot({ path: `screenshots/failure-${Date.now()}.png`, fullPage: true });
        await sendSlackAlert(`Тест упал: ${error.message}`);
        throw error;
    }
});

Особенности организации алертов:

  • Сообщение должно содержать ссылку на скриншот или видео.
  • Стоит включать краткий контекст: название теста, URL страницы, стек ошибки.
  • При массовых падениях следует использовать батч-уведомления, чтобы не перегружать канал.

Глобальная обработка падений

Для более крупных проектов можно централизовать обработку падений с использованием глобальных хуков Playwright:

// global-setup.js
const { chromium } = require('@playwright/test');

module.exports = async () => {
    process.on('unhandledRejection', async (reason) => {
        console.error('Необработанное исключение:', reason);
        // Здесь можно добавить отправку уведомления
    });
};

Использование хуков позволяет фиксировать ошибки, которые возникают вне конкретного теста, например, при настройке окружения.

Рекомендации по эффективному алертингу

  1. Всегда сохранять визуальные артефакты (скриншоты, видео) — без них анализ падения сильно замедляется.
  2. Сохранять контекст страницы — URL, заголовки, состояние элементов.
  3. Использовать интеграции с системами уведомлений для оперативного реагирования.
  4. Централизовать обработку ошибок через глобальные хуки, чтобы не дублировать код в каждом тесте.
  5. Адаптировать сообщения под команду — кратко, ясно, с указанием точного места падения.

Практика при CI/CD

При запуске тестов в CI/CD важно, чтобы алерты были автоматизированы и не требовали ручного вмешательства:

  • Настройка сохранения артефактов в пайплайне (artifacts в GitLab CI, actions/upload-artifact в GitHub Actions).
  • Отправка уведомлений в корпоративные каналы.
  • Логи и скриншоты должны быть доступны для анализа из любого места.

Эффективный алертинг при падении тестов повышает скорость обнаружения проблем и качество поддержки автоматизации. Playwright предоставляет все необходимые инструменты для реализации такой системы, включая встроенные хуки, возможности записи видео и скриншотов, а также гибкую интеграцию с внешними системами уведомлений.

Оглавление