Обработка отклоненных промисов

Axe-core — это библиотека для автоматизированного тестирования доступности веб-приложений, написанная на JavaScript. Она предоставляет API для анализа DOM-дерева страницы и выявления проблем доступности (accessibility issues). Одним из ключевых аспектов работы с Axe-core является асинхронность, так как большинство операций по сканированию и генерации отчётов выполняются через промисы.

Асинхронные операции и промисы

Методы Axe-core, такие как axe.run(), возвращают промис, который разрешается объектом с результатами анализа. В стандартной схеме использования промиса важно учитывать два состояния: resolved (успешно выполнено) и rejected (ошибка или исключение). Игнорирование отклонённых промисов может привести к неожиданным сбоям тестов и пропущенным ошибкам доступности.

Пример базового вызова:

axe.run(document).then(results => {
    console.log(results.violations);
}).catch(error => {
    console.error('Ошибка при запуске Axe-core:', error);
});

Здесь .catch() обеспечивает обработку отклонённого промиса, который может возникнуть из-за:

  • некорректного DOM;
  • проблем с загрузкой стилей или скриптов;
  • ошибок конфигурации Axe-core.

Обработка ошибок с использованием async/await

Современные проекты часто используют синтаксис async/await, что делает код более читаемым и структурированным. Важно оборачивать асинхронный вызов в try/catch блок для надёжной обработки отклонённых промисов:

async function runAccessibilityTest() {
    try {
        const results = await axe.run(document);
        console.log(results.violations);
    } catch (error) {
        console.error('Ошибка Axe-core:', error);
    }
}

Особенность работы с await заключается в том, что любая ошибка внутри промиса будет выброшена как исключение, что требует обязательной обработки через try/catch.

Типичные причины отклонения промисов в Axe-core

  1. Недоступный или пустой DOM Если переданный в axe.run() объект документа не содержит элементов, промис может быть отклонён с сообщением о невозможности проведения анализа.

  2. Некорректная конфигурация правил Настройка правил через объект axe.configure() должна содержать корректные ключи и значения. Ошибки конфигурации напрямую вызывают отклонение промиса.

  3. Проблемы с внешними ресурсами Стили, шрифты или скрипты, которые не загрузились до вызова axe.run(), могут привести к ошибкам в вычислении видимости элементов.

Обработка нескольких промисов

Если требуется запуск Axe-core на нескольких частях приложения одновременно, полезно использовать Promise.allSettled() для предотвращения остановки всех тестов при отклонении одного промиса:

const targets = [document.querySelector('#header'), document.querySelector('#main')];

const results = await Promise.allSettled(targets.map(target => axe.run(target)));

results.forEach((result, index) => {
    if (result.status === 'fulfilled') {
        console.log(`Результаты для элемента ${index}:`, result.value.violations);
    } else {
        console.error(`Ошибка для элемента ${index}:`, result.reason);
    }
});

Такой подход позволяет сохранить информацию о каждой попытке анализа и не потерять данные из-за одной ошибки.

Логирование и обработка ошибок в тестовой среде

В автоматизированном тестировании важно различать ошибки выполнения Axe-core и реальные нарушения доступности:

  • Ошибки выполнения (rejected promise) — проблемы с самим анализом, требующие корректировки кода или конфигурации.
  • Нарушения правил доступности — нормальный результат анализа, который не должен приводить к отклонению промиса.

Рекомендуется отделять эти два типа обработки, чтобы CI/CD не падал из-за мелких ошибок и в то же время фиксировались реальные проблемы доступности.

Практика безопасного вызова Axe-core

  • Всегда использовать .catch() или try/catch для обработки отклонённых промисов.
  • Логировать полное сообщение ошибки для последующей диагностики.
  • Проверять корректность DOM и загруженных ресурсов перед вызовом axe.run().
  • Использовать Promise.allSettled() при параллельной проверке нескольких элементов.
  • Разделять ошибки выполнения и нарушения правил для корректной интеграции с тестовыми фреймворками.

Обеспечение правильной обработки отклонённых промисов повышает стабильность тестов доступности и позволяет получать надёжные отчёты без пропуска критических проблем в интерфейсе.

Оглавление