sound_right 23 апр в 09:27

Как увидеть, что именно покрывают UI-тесты — прямо на сайте и в реальном времени

21 мин

1.7K

Тестирование IT-систем*Тестирование веб-сервисов*Python*ReactJS*TypeScript*

Вступление

Представьте, вы заходите на страницу — и сразу видите, какие элементы были протестированы, а какие забыты. Прямо, как на скриншоте ниже:

А потом… просыпаетесь. Опять сон. Мечты об идеальном покрытии.

Но стоп. Теперь это не сон. Это мой инновационный инструмент для визуализации покрытия UI автотестов. Готовьтесь — будет интересно.

Классика жанра — сначала о проблеме

Пишем мы, значит, UI-тесты. Запускаем. Они что-то проверяют, что-то кликают, иногда даже баги находят. Но вот вопрос — что именно они проверяют? И насколько качественно?

А кнопку в настройках юзера, которая в модалке?
А то, что при незаполненной форме кнопка неактивна?
А если текст обрезался в navbar-ре — кто это заметит?

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

Как на эти вопросы сейчас отвечают?

Если бы мы тестировали API — у нас был бы Swagger, можно было бы считать покрытие по контракту. А что делать с UI?

Ну давайте честно, как сейчас обычно проверяют покрытие UI-тестов?

Никак

Да-да. Просто никак. Обычно покрытие UI-тестов вообще не измеряется. Соответственно — понять, что покрыто, а что нет — невозможно. От слова совсем.

Через дебаг

Можно, конечно, углубиться в тесты, пошагово пройтись по каждому, посмотреть, что он делает. Но если тест большой, с кучей логики и условий — просмотр и анализ одного такого теста может занять час. А то и больше.

Ручками

Можно строить матрицы покрытий, таблицы, рисовать дашборды в TMS. Выглядит красиво. Но по факту — всё устаревает быстрее, чем успевает появиться. И если вы когда-то вручную пытались оценить покрытие UI — вы знаете, как быстро это становится бессмысленным.

Проблема реальная

Сейчас нет ни одного нормального способа понять, что реально покрыто UI-тестами. Но... Теперь есть.

А если бы...

А теперь представьте: у нас есть инструмент, который в реальном времени, прямо на сайте, показывает:

какие элементы покрыты тестами
какие действия с ними выполнялись
и даже историю взаимодействия с каждым элементом

Тогда всё меняется. Открываешь нужную страницу → нажимаешь на кнопку → видишь всю карту покрытия: что кликали, что проверяли, а что — игнорировали.

Звучит, как что-то из мира фантазий. Без костылей? Без магии? Без шаманства? С любым фреймворком? Настраивается за два клика? Ага. Добро пожаловать в реальность.

Встречайте: ui-coverage-tool

Инновационный инструмент для визуализации UI-покрытия, который на момент написания этой статьи:

не имеет аналогов ни по концепции, ни по функционалу
работает с любыми фреймворками
встраивается за пару минут
и даёт вам интерактивную карту покрытий UI прямо в браузере

Лично считаю это огромным прорывом в индустрии UI-автоматизации. И сейчас расскажу, как это работает под капотом, зачем это всё нужно — и как начать пользоваться уже сегодня.

Архитектура отчета

Начнём сразу с места в карьер. Как устроен ui-coverage-tool? Как ему удаётся так гибко встраиваться в страницу и рисовать элементы прямо поверх живого приложения?

На схеме выше видно, как устроено взаимодействие между отчётом и фреймом. И, на самом деле, архитектура тут максимально простая — и в этом её сила.

Вот как это работает по шагам:

На сайт, для которого нужно измерить покрытие, встраивается скрипт с агентом.
Этот сайт открывается внутри iframe прямо в отчёте.
Отчёт и агент начинают взаимодействовать между собой по протоколу Web Messaging (aka postMessage).
Агент может передавать данные отчёту, а отчёт — давать команды агенту.

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

Как это выглядит на практике?

Предельно просто:

Отчёт говорит агенту: «Подсвети элемент, который был покрыт тестами»
Агент получает команду и выполняет
Пользователь видит на экране визуально подсвеченный элемент

И всё это — без шаманства, без костылей, с любой страницей и за считанные миллисекунды.

Главная фишка — не в подсветке

Самое главное здесь — даже не сама визуализация, а движок, который стоит за этим. Он:

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

Именно это позволяет построить отчёт, который можно открывать где угодно — от CI до локалки, от GitHub Pages до Allure.

Есть ли у подхода лимитации?

Если говорить честно — нет. Если и есть какие-то ограничения, то не в архитектуре, а в реализации (например, если что-то криво встроено на стороне проекта). Но глобально — подход устойчив, масштабируем и не зависит от среды.

А что с альтернативами?

1. Снапшоты (Playwright Trace, Cypress UI Coverage и другие)

Можно после каждого действия теста делать снапшот и потом поверх него визуализировать покрытие. Так делают, например, Playwright Trace Viewer или Cypress UI Coverage.

Но есть нюанс. Снапшоты — тяжёлые. Очень тяжёлые.

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

Для сравнения: ui-coverage-tool со всеми данными, историей, скриптами, UI, картами действий и интерактивом весит… ~1.1 МБ

Вдумайтесь. Полноценный отчёт меньше, чем ваша аватарка в Slack.

2. Браузерные плагины

Кто-то может сказать: «А давай я сделаю расширение для Chrome, которое всё покажет!». Звучит ок… до тех пор, пока:

не понадобилось открыть отчёт в Safari
не понадобилось сделать отчёт публичным (GitHub Pages?)
не захотелось вшить туда полноценный UI на React/Vue/Angular
не встал вопрос безопасности и доступов
не пришла идея прикрепить отчёт к Allure

Ответ на всё это — плагин не справится. А ui-coverage-tool — легко. Он — это просто HTML + JS + данные. Всё самодостаточное, публикуемое, клонируемое, кросс-браузерное.

3. Инъекция скриптов в iframe

Есть и третий способ — открыть сайт во фрейме и через iframe.contentWindow.document рисовать там что-нибудь. Но тут вы быстро упрётесь в security hell:

cross-origin ошибки
Content-Security-Policy
отсутствие доступа к DOM
невозможность внедриться в SPA без релоада

Я этот путь пробовал в самом начале. И быстро отказался — слишком нестабильно, слишком много ограничений.

Сейчас ui-coverage-tool использует postMessage, а это стабильный, безопасный и нативный способ общения между окнами.

И ещё одна магия…

Когда мы работаем не со снапшотом, а с реальным сайтом, мы можем:

Загнать его в любое состояние (например, открыть модалку, ввести текст, переключить таб)
И уже на этом состоянии — нажать на кнопку покрытия
И получить живую, актуальную карту взаимодействий элементов, прямо по ходу теста

Это не просто удобно — это новый уровень осознанности в автотестах.

Всё гениальное — просто

Вот и весь секрет: минимум архитектурных компонентов + максимум пользы и гибкости. ui-coverage-tool — это не просто отчёт, это визуальный отладчик покрытия, который реально работает.

Если вы писали UI-тесты — вы знаете, насколько это может быть полезно.

Как это работает?

Теперь давайте разберёмся, как именно работает сбор покрытия в ui-coverage-tool. Спойлер: всё до безобразия просто. Без танцев, без магии, без боли.

Шаг 1. Встраиваем агента

Чтобы агент смог подсвечивать элементы и собирать действия — его нужно встроить прямо в сайт или приложение. Как это делается? Да просто:

<script src="https://nikita-filonov.github.io/ui-coverage-report/agent.global.js"></script>

Это весь секрет. Один скрипт — и ваш сайт уже умеет взаимодействовать с отчётом. Всё. Больше ничего делать не нужно.

Шаг 2. Автотесты запускаются — трекер работает

Когда запускаются автотесты, в дело вступает трекер — это часть ui-coverage-tool, которая напрямую встраивается в тесты.

После каждого действия на странице (будь то click, fill, assert visible, assert text и другие), трекер:

сохраняет селектор
сохраняет его тип (XPath, CSS)
фиксирует само действие (click, fill, select, check, и другие)

Каждое взаимодействие превращается в небольшой JSON-файл, который сохраняется в папку coverage-results.

Таким образом, собирается реальное, фактическое покрытие интерфейса действиями из автотестов, а не "где-то там мы вроде кликали, наверное, но это не точно".

Шаг 3. Генерируем отчёт

После завершения тестов, одной простой командой:

ui-coverage-tool save-report

вы получаете:

HTML-отчёт — интерактивный, живой, визуальный, удобный. Можно:

открывать в браузере
прикреплять к Allure
выкладывать на GitHub/GitLab Pages
шарить коллегам и менеджерам
или просто открыть локально и порадоваться

JSON-отчёт — тот же самый контент, но в машиночитаемом виде. Его можно:

скормить аналитике
вывести summary в консоли
отправить в сторонние системы
использовать в CI для оценки динамики покрытия

И что важно — весь HTML-отчёт упакован в один файл. Один файл, один клик, максимум информации.

Вы спросите — и всё?

Да, и всё. А что еще нужно? Никакой магии, никакой боли, никаких танцев с inject_js, wait_for_selector и так далее. Вся фишка ui-coverage-tool — в его простоте и универсальности.

А что под капотом?

Если коротко:

Обвязка на Python/Обвязка на TypeScript/JavaScript
Собирает JSON-чики по ходу тестов
Управляет историей (можно видеть не только последнее, но и всё, что было)
Аггрегирует данные
Генерирует финальные отчёты

И всё это — прозрачно, удобно и стабильно. Без костылей.

Работает везде

Хоть на Playwright, хоть на Selenium, хоть на чём-то кастомном — всё работает.

Потому что ui-coverage-tool не зависит от фреймворка. Он просто сохраняет взаимодействия с DOM и всё остальное ему до лампочки. Вот и весь секрет. Всё максимально просто, но при этом безумно эффективно.

Концепция

ui-coverage-tool создан с одной простой, но мощной идеей — показать, что именно делают ваши UI тесты на самом деле, а не только на словах. Он решает сразу несколько задач:

Автоматизация сбора покрытия

Один раз настроили — и забыли. Покрытие собирается и сохраняется автоматически во время выполнения автотестов. Ручной труд? Нет, спасибо.

Визуализация на живом сайте

Это не скриншоты и не pdf/html-снапшоты. Отчет отображается на живой странице, прямо в браузере. Хотите посмотреть, что покрыто в конкретной форме, модалке или редком состоянии интерфейса? Просто переключитесь в нужное состояние сайта и увидите результат. Это особенно важно для сложных веб-приложений с множеством сценариев, условий, состояний.

Доступность для всей команды

От автоматизаторов до проджектов и аналитиков — все могут открыть отчет и за секунды понять, какие части интерфейса не покрыты. И поверьте, таких зон больше, чем кажется. Удивление при первом запуске — это нормально: вы вдруг замечаете, что даже банальные кнопки никто не проверяет.

Скорость и легкость

Инструмент не тормозит тесты и не генерирует гигабайты снапшотов. Он просто сохраняет маленькие JSON-файлы, например, такого вида:

{
  "app": "ui-course",
  "selector": "//*[@data-testid='navigation-navbar-welcome-title-text']",
  "action_type": "VISIBLE",
  "selector_type": "XPATH"
}

Каждое действие в тесте превращается в такой файл. И всё — этого уже достаточно, чтобы собрать визуальный отчет.

Что нам это даёт?

Объективность. Покрытие становится реальным, а не "вроде мы там что-то проверяли". Оно отражает именно те действия, которые реально выполнялись в браузере, и это видно визуально.
Выявление слепых зон. Открыли модалку — а половина полей в ней вообще не покрыта тестами. Никто бы и не заметил без визуального покрытия. А значит — потенциальный баг уже поджидает в тени.
Экономия ресурсов. Пробовали когда-нибудь вручную собирать покрытие? Таблицы, схемы, mind map'ы, wiki-странички? Всё это устаревает, требует времени, и стоит компании кучу денег (буквально). ui-coverage-tool делает это автоматически, мгновенно и бесплатно.

Почему лучше, чем альтернативы?

А какие вообще есть альтернативы?

Cypress UI Coverage — да, крутой, но:
- работает только с Cypress и JS
- платный
- покрытие основано на снапшотах, а не live view

А если взять Playwright + Trace Viewer (трейсинг) + ui-coverage-tool — получаем весь функционал Cypress UI Coverage, но бесплатно, с поддержкой любых языков, и без ограничений.

Настройка агента

Чтобы красиво и корректно визуализировать покрытие прямо на сайте, нужно встроить небольшой скрипт агента в HTML вашего приложения. Делается это элементарно — добавьте в HTML следующую строку:

<script src="https://nikita-filonov.github.io/ui-coverage-report/agent.global.js"></script>

После этого:

агент автоматически инициализируется на странице
вы сможете открыть свой сайт внутри отчета ui-coverage-tool
и увидеть, какие элементы покрыты тестами, а какие нет — прямо в реальном времени

Безопасно ли это?

Да, безопасно. И вот почему:

Это обычная практика. Если вы когда-либо подключали на сайт Google Analytics, UI-библиотеку или, скажем, рекламу через Google Ads — вы уже вставляли внешние скрипты. Агент работает точно так же: это стандартная и безопасная практика.
Полностью Open Source. Весь исходный код доступен по ссылке: ui-coverage-report. Вы можете в любой момент посмотреть, что именно делает агент, и убедиться, что там нет ничего подозрительного.

А что насчёт продакшна?

Хотя агент безопасен, на продакшн я бы всё же не советовал его вставлять:

это лишний внешний скрипт, пусть и маленький
он будет загружаться при каждом открытии страницы (хотя и закешируется)
да и зачем он там, если вы не планируете прямо на боевом окружении смотреть отчёты?

Рекомендую использовать на: dev, staging, test и других нефинальных контурах.

Установка

Прежде чем начать работу с ui-coverage-tool, необходимо установить библиотеку:

pip install ui-coverage-tool

После установки вы можете использовать библиотеку как в коде, так и через CLI-интерфейс (Command Line Interface).

Импорт в коде

from ui_coverage_tool import UICoverageTracker, SelectorType, ActionType

CLI-интерфейс

Вместе с установкой становится доступна команда:

ui-coverage-tool --help

Библиотека поставляется с максимально простым CLI — всего две основные команды:

Генерация отчёта. ui-coverage-tool save-report — эта команда собирает все накопленные данные покрытия и генерирует HTML и JSON-отчёты. HTML-отчёт — это один самодостаточный файл, который можно открыть в любом браузере и сразу увидеть результат.
Просмотр конфигурации. ui-coverage-tool print-config — позволяет вывести текущую конфигурацию в консоль. Полезно, если нужно убедиться, что конфиги подтянулись корректно и всё работает как надо.

Важно: запуск команд

Все команды ui-coverage-tool должны запускаться строго из корня проекта. Не из директории с тестами, не из подпапки, не "выше" проекта — только из корневой директории, где установлена сама библиотека.

Если запуск будет из другой директории — поведение может быть непредсказуемым: часть путей может не разрешиться, сборка покрытия — не выполниться, а отчёт — не сгенерироваться.

Настройки

Для корректной работы ui-coverage-tool необходимо указать настройки. Библиотека поддерживает несколько способов конфигурации:

.env файл — для объявления через переменные окружения. Пример .env
ui_coverage_config.yaml — конфигурация в YAML-файле. Пример YAML
ui_coverage_config.json — конфигурация в JSON-файле. Пример JSON

Все способы работают аналогично, формат просто выбирается под ваш проект. Ниже рассмотрим пример в формате YAML.

Пример ui_coverage_config.yaml

services:
  - key: "my-ui-app"  # (обязательно) Уникальный ключ приложения
    url: "https://my-ui-app.com/login"  # (обязательно) URL-адрес точки входа в приложение, например, страница логина
    name: "My UI App"  # (обязательно) Название приложения, отображается в отчёте
    tags: [ "UI", "PRODUCTION" ]  # (опционально) Метки для фильтрации/группировки
    repository: "https://github.com/my-ui-app"  # (опционально) Ссылка на репозиторий с кодом

results_dir: "./coverage-results"  # (опционально) Папка, куда сохраняются временные результаты покрытия

history_file: "./coverage-history.json"  # (опционально) Путь к файлу с историей покрытия
history_retention_limit: 30  # (опционально) Количество последних записей истории, которые нужно сохранять

html_report_file: "./index.html"  # (опционально) Путь к итоговому HTML-отчёту
json_report_file: "./coverage-report.json"  # (опционально) Путь к итоговому JSON-отчёту

Что важно знать:

apps — это единственное обязательное поле. Остальные настройки являются опциональными.
Если вы не хотите генерировать какой-либо из отчетов, просто передайте null. Например: html_report_file: null или json_report_file: null
Конфигурационный файл должен находиться в корне проекта или в директории, откуда запускается CLI/тесты.

Если базовые настройки заданы — библиотека готова к использованию, и можно начинать собирать покрытие.

Важно: расположение конфигов

Все конфигурационные файлы ui-coverage-tool обязательно должны находиться в корне проекта. Не в папке .config, не в tests/ui/config, не где-то "рядом", а именно в корневой директории. Если конфиги находятся вне корня — инструмент может не найти их, или начать использовать дефолтные значения, что приведёт к неполной или некорректной работе.

Просто правило: всё, что связано с ui-coverage-tool — живёт в корне.

Использование

Начать использовать ui-coverage-tool — проще простого. Всё интуитивно и гибко. Ниже пример для Playwright, но если вы используете Selenium — всё будет практически так же, только немного отличается синтаксис.

Вот типичный автотест с трекером покрытия:

from playwright.sync_api import sync_playwright

# Импортируем основные компоненты инструмента:
# - UICoverageTracker — основной класс для трекинга
# - SelectorType — тип селектора (CSS, XPATH и другие)
# - ActionType — тип действия (CLICK, FILL, CHECK_VISIBLE и другие)
from ui_coverage_tool import UICoverageTracker, SelectorType, ActionType

# Создаём экземпляр трекера. 
# Значение `app` — это ключ приложения (должно совпадать с ключом в конфиге UI_COVERAGE_APPS)
tracker = UICoverageTracker(app="my-ui-app")

with sync_playwright() as playwright:
    browser = playwright.chromium.launch()
    page = browser.new_page()
    page.goto("https://my-ui-app.com/login")

    # Вводим логин
    username_input = page.locator("#username-input")
    username_input.fill('user@example.com')

    # Фиксируем это действие в трекере
    tracker.track_coverage(
        selector='#username-input',  # CSS-селектор
        action_type=ActionType.FILL,  # Тип действия: ввод текста (FILL)
        selector_type=SelectorType.CSS  # Тип селектора: CSS
    )

    # Нажимаем на кнопку входа
    login_button = page.locator('//button[@id="login-button"]')
    login_button.click()

    # И снова фиксируем это действие
    tracker.track_coverage(
        selector='//button[@id="login-button"]',  # XPath-селектор
        action_type=ActionType.CLICK,  # Тип действия: клик
        selector_type=SelectorType.XPATH  # Тип селектора: XPath
    )

После каждого вызова tracker.track_coverage(...):

создаётся маленький JSON-файл с информацией об элементе и действии
файл сохраняется в папку ./coverage-results
по одному файлу на каждое взаимодействие — удобно и для анализа, и для генерации итогового отчёта

Использование с несколькими приложениями

Если ваши автотесты работают с несколькими интерфейсами или доменами (например, admin и student), вы можете просто создать несколько трекеров:

admin_app_tracker = UICoverageTracker(app="admin-app")
student_app_tracker = UICoverageTracker(app="student-app")

После этого просто используйте нужный трекер в нужном контексте — и всё покрытие будет разделено по приложениям.

Что дальше?

Когда все тесты завершены — можно запустить генератор отчёта. Он соберёт все JSON-файлы из coverage-results, агрегирует их, и вы получите:

красивый интерактивный отчёт
наглядное покрытие для каждой страницы
список элементов, которые не покрыты тестами вообще

Real Work Example: красивая интеграция с PageFactory

В примере выше мы просто вызвали tracker.track_coverage(...) вручную — и да, это работает. Но на реальных проектах UI автотесты обычно строятся не на голом Playwright или Selenium, а с использованием PageObject, а если проект зрелый — то и с PageComponent и PageFactory.

И тут начинается самое интересное: как встроить трекинг покрытия максимально элегантно, без того, чтобы лезть в каждый тест и копировать вызовы трекера?

Ответ: интегрируем покрытие прямо в PageFactory элементы — и всё будет работать само.

Базовый элемент: BaseElement

Создаём базовый элемент BaseElement, от которого будут наследоваться все остальные (Input, Button, Icon, и другие) — и добавляем туда сбор покрытия.

import allure
from playwright.sync_api import Page, Locator, expect
from ui_coverage_tool import ActionType, SelectorType

from coverage import tracker  # наш трекер покрытия
from tools.logger import get_logger

logger = get_logger("BASE_ELEMENT")


class BaseElement:
    def __init__(self, page: Page, locator: str, name: str):
        self.page = page
        self.name = name
        self.locator = locator

    @property
    def type_of(self) -> str:
        return "base element"

    def get_locator(self, nth: int = 0, **kwargs) -> Locator:
        # Возвращаем playwright-локатор по data-testid
        locator = self.locator.format(**kwargs)
        step = f'Getting locator with "data-testid={locator}" at index "{nth}"'

        with allure.step(step):
            logger.info(step)
            return self.page.get_by_test_id(locator).nth(nth)

    def get_raw_locator(self, **kwargs) -> str:
        # Возвращаем XPath локатор, который будет использоваться для трекинга
        return f"//*[@data-testid='{self.locator.format(**kwargs)}']"

    def track_coverage(self, action_type: ActionType, **kwargs):
        # Сам метод трекинга
        # Оборачиваем в метод, чтобы избежать дублирования
        tracker.track_coverage(
            selector=self.get_raw_locator(**kwargs),  # Получаем локатор
            action_type=action_type,  # Тип действия: CLICK, FILL и другие
            selector_type=SelectorType.XPATH  # Указываем, что это XPath
        )

    def click(self, nth: int = 0, **kwargs):
        # Метод клика, с логированием и трекингом
        step = f'Clicking {self.type_of} "{self.name}"'

        with allure.step(step):
            locator = self.get_locator(nth, **kwargs)
            logger.info(step)
            locator.click()

        # Сохраняем покрытие
        self.track_coverage(ActionType.CLICK, **kwargs)

Далее — дело техники

Теперь мы можем создать конкретные элементы, переопределяя type_of и, при необходимости, адаптируя локаторы:

class Input(BaseElement):
    @property
    def type_of(self) -> str:
        return "input"

    def get_locator(self, nth: int = 0, **kwargs) -> Locator:
        # Возвращаем только вложенные <input> внутри элемента
        return super().get_locator(nth, **kwargs).locator('input')

    def get_raw_locator(self, **kwargs) -> str:
        # Аналогично: для XPath добавляем вложенный input
        return f'{super().get_raw_locator(**kwargs)}//input'

Важно! Поскольку track_coverage использует get_raw_locator() — мы легко управляем тем, что именно будет попадать в покрытие.

Используем PageFactory в компонентах

Теперь ваши компоненты и страницы вообще не знают о сборе покрытия. Всё происходит за счёт наследования и композиции.

class LoginFormComponent(BaseComponent):
    def __init__(self, page: Page):
        super().__init__(page)

        self.username_input = Input(page, "username-input", "Username")

    def fill(self, username: str):
        # Просто вызываем fill — покрытие соберётся автоматически внутри Input
        self.username_input.fill(username)

Почему это удобно?

Вы ничего не меняете в тестах — все изменения только в PageFactory
Всё покрытие инкапсулировано и централизовано
Очень легко масштабировать на десятки и сотни компонентов
И это буквально 15 минут работы, чтобы покрытие появилось во всех тестах проекта

Нужно больше?

У меня есть статьи, где я подробнее рассказываю про такой подход к PageFactory и организации автотестов. Почитайте, уверен — будет полезно:

В завершение — вы абсолютно не обязаны делать именно так. Хотите — вызывайте track_coverage вручную где нужно, или через хуки, или даже оборачивайте элементы через декораторы. Главное — чтобы было удобно вам.

Но подход через PageFactory — это как раз тот случай, когда "красиво, удобно и масштабируемо". Просто и гениально.

Отчет

После запуска тестов инструмент автоматически соберет данные о покрытии и сохранит их в папку coverage-results. Эти данные будут использованы для генерации отчетов, которые можно сохранить в разных форматах. Чтобы создать отчет, необходимо выполнить команду:

ui-coverage-tool save-report

Команда save-report генерирует несколько файлов:

index.html — HTML отчет в виде единого файла. Этот файл можно открыть в браузере, опубликовать на платформе GitHub Pages, GitLab Pages или просто поделиться с коллегами. Пример HTML отчета.
coverage-report.json — JSON отчет, содержащий все данные о покрытии. Этот файл можно использовать, например, для вывода краткой информации о покрытии в консоль или для загрузки в сторонние системы.
coverage-history.json — Файл для сохранения истории покрытия. Если вам нужно отслеживать изменения покрытия с течением времени, то при следующем запуске отчета этот файл должен быть доступен. Он не должен модифицироваться вручную — все изменения в нем происходят автоматически через инструмент. При этом файл истории можно разместить в любом месте, просто укажите путь к нему в настройке history_file.

HTML-отчёт: Наглядно. Быстро. Полезно.

И вот мы подобрались к самому вкусному — HTML-отчёту, тому самому, ради чего всё это покрытие вообще собиралось. Давайте разберём его по частям.

Config — конфигурация отчёта

Первое, что мы видим — блок с метаинформацией:

Название тестируемого приложения
Ссылка на приложение (оно же открывается внизу во фрейме)
Дата и время генерации отчёта
Теги, environment, автор и любые другие метаданные, которые вы захотите туда добавить

Total number of elements / Total number of actions

Следом идут два красивых и полезных графика:

Total number of elements — сколько уникальных элементов было задействовано во время всех автотестов. Показывает рост покрытия по элементам.
Total number of actions — сколько всего действий было совершено: кликов, проверок, ввода текста и других.

Эти графики — настоящие индикаторы прогресса. Если вы только начали покрытие, увидите рост с каждой новой итерацией тестов. Это прям мощный мотивационный элемент.

История действий: динамика по типам

Центральный график отчёта — stacked bar chart, где:

Каждый столбец — момент времени (по дате/времени)
Цветовые зоны в столбце — типы действий: click, check visible, check text, fill, и другие.
Чем выше столбец — тем больше действий

Пример: вы замечаете, что у вас почти нет проверок видимости (check visible). Вносите правки в тесты — и в следующем отчёте эта зона на графике начинает расти. Красота.

Это прямо фидбек-петля между улучшениями и их результатами.

Фрейм с приложением: наглядное покрытие

И вот она, вишенка на торте — фрейм с вашим приложением:

Приложение/сайт загружается прямо в отчёте
Поверх него подсвечиваются элементы, которые покрыты тестами
У каждого элемента может быть бейдж с количеством типов действий

Это визуализация покрытия “поверх” настоящей страницы. Видно всё: что кликали, что проверяли, где текст заполнялся и другое.

Как это работает?

Флоу простой и понятный:

Открываете отчёт. Видите структуру, графики, фрейм с приложением.
По умолчанию подсветки нет. Чтобы она появилась, нажмите на кнопку Refresh на тулбаре.
Перешли на другую страницу — снова нажмите Refresh. Подсветка обновится под новую DOM-структуру.
Модалка/попап — те же правила. Открыли модалку → нажали Refresh → закрыли → снова Refresh, если бейджи “зависли”. Это нормально, DOM не всегда предсказуем.

Правило простое: “в любой непонятной ситуации — нажмите Refresh”. Он пересинхронизирует покрытие с текущей страницей

Настройки и фильтры

Настраиваемые цвета для бейджей и рамок. Если на вашем UI плохо видно — можно подкрутить прямо в конфиге.
Фильтрация действий — хотим увидеть только click или только check text? Не проблема.
Фильтрация по группам — например, только все “проверки” (check visible, check text, check hidden, check disabled и другие)

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

Подробности, которые решают: модалка элемента

Но и это ещё не всё. Если кликнуть на бейдж рядом с элементом во фрейме — откроется модальное окно с полной информацией об этом элементе. Прямо как в отладчике, только красивее и понятнее. Вот что вы там увидите:

Селектор: всё, что нужно знать

Тип селектора (например, xpath, css)
Само значение селектора

Это особенно полезно, если у вас несколько одинаковых элементов или сложные кастомные компоненты — всегда можно понять, откуда он взялся и как до него добраться.

Таблица действий: кто, когда и сколько

Далее идёт таблица действий, в которой указано:

Какие именно действия совершались (click, check visible, fill, и другие)
Сколько раз каждое действие было выполнено

Это уже не просто покрытие, а телеметрия. Можно отследить, какие элементы используются чаще, какие игнорируются, и где тесты “халтурят”.

История элемента: всё, как было

Ниже — история этого конкретного элемента на протяжении всех запусков тестов. Это реально киллер-фича.

Например:

Решили, что все кнопки перед кликом нужно проверять на enabled.
Смотрим историю элемента и видим:
— раньше был только click,
— теперь есть и check enabled перед ним.

Вот он — контроль эволюции качества. И всё это по каждому элементу. Это такой уровень прозрачности, которого раньше не было ни в одном UI-репорте.

Таблица селекторов: быстрый доступ ко всему

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

Мультидоменность: один отчёт — много приложений

Тестируете сразу несколько приложений, каждый на своём домене? Вообще не проблема.

Все данные можно собрать в один отчёт
Переключение между приложениями — через выпадающий список
Отчёт адаптируется под каждое приложение

Больше никаких “10 вкладок — 10 отчётов”. Всё централизовано и удобно.

Темная тема

Ну и конечно же — темная тема. Глаза не текут, смотреть приятно. Работает из коробки и переключается в один клик.

Итог: Один HTML — максимум пользы

Всё, что вам нужно для анализа и улучшения UI-тестов, теперь в одном HTML-файле:

Наглядное покрытие
Динамика и история
Глубокая детализация по каждому элементу
Возможность фильтрации и поиска
Мультидоменность
Быстрая интеграция

С таким отчётом вы не просто “запускаете автотесты”, а развиваете культуру качества в команде. Пора перестать гадать — покрыто или нет. Теперь это видно. Понятно. Проверяемо.

Где это вообще может пригодиться?

1. Когда хочется понять: “А вообще что-нибудь покрыто?”

Написал тесты. Посмотрел в терминал. Всё зелёное. Ну вроде молодец? А потом открываешь отчёт — и видишь, что по факту проверяется три кнопки и один h1. Остальное — гуляет. А ты думал, у тебя "всё под контролем".

С отчётом сразу видно:

какие элементы трогали;
какие действия над ними были;
было ли что-то полезное вроде проверок, или просто потыкали и забыли.

2. Ревью автотестов без экстрасенсорики

Приходит тебе MR с тестами. Новый функционал. Глазами читать? Ну можно. Но хочется быстро понять: тест реально что-то проверяет или просто делает вид?

Открываешь отчёт — и всё видно:

есть ли действия с ключевыми элементами;
проверяются ли состояния/тексты;
ничего ли важного не пропустили.

И это не “чувствую, что нормально” — это чётко видно глазами. Как рентген, только без излучения.

3. Планирование задач, как взрослые люди

“А какие части UI у нас вообще не покрыты тестами?” — классика. С этим инструментом можно буквально ткнуть в отчёт и сказать:

вот страница без единого теста;
вот элементы, на которые кликают, но ничего не проверяют;
а тут вообще UI-призрак — его никто не видит.

Дальше — просто: оформляешь задачи, назначаешь приоритет, укрепляешь покрытие. Всё как в настоящей разработке, только с реальными данными.

4. Покажи это продакту — и пусть отстанет

Продакт спрашивает:

“А поиск точно тестируется?”
И ты такой: “Ну, эээ... вроде да... сейчас найду в коде...”

Нет. Ты просто открываешь отчёт, показываешь страницу — и видно:

есть ли этот селектор;
тестировался ли он;
что с ним делали (кликали, проверяли, игнорировали).

Минимум слов — максимум пользы. Особенно когда хочешь впечатлить заказчика не только графиками в Excel.

5. Контроль эволюции тестов (если ты не просто “написал и забыл”)

Когда начинаешь следить за тем, что покрыто, а что — нет, появляется новая суперспособность: понимать, куда всё движется.

Был просто клик → стало ещё и проверка текста.
Была видимость → добавили доступность.
А где-то, наоборот, что-то отвалилось и стало хуже.

Теперь ты не просто “кажется, тестов стало больше”, а реально видишь, где стало лучше, а где надо пнуть.

6. Аналитика по-взрослому

В отчёте можно нарыть инсайты:

у нас вообще есть проверки доступности?
мы проверяем disabled у кнопок или просто жмём на всё подряд?
может, у нас вообще нигде input'ы не валидируются?

И на основе этого не просто “дописать пару тестов”, а выстроить нормальную стратегию покрытия.

Заключение

В итоге, давайте честно и по пунктам: ui-coverage-tool — это не просто ещё один инструмент. Это новый уровень.

Почему стоит обратить внимание?

Нет достойных аналогов. На момент написания — не существует ни одного другого инструмента, который бы приближался по функциональности, удобству и визуализации к ui-coverage-tool. Это реально первая ласточка нового поколения в UI-автоматизации.
Инновация без магии. Звучит как магия: визуальное покрытие, динамика, история, фильтрация... Но внутри — чистая логика, никакого шаманства. Всё построено на понятной архитектуре, легко адаптируется под любой язык и фреймворк.
Без костылей. Никаких хаков, обходов или нестабильных решений. Всё написано чисто, с нуля, продуманно и с акцентом на расширяемость.
Простая, но мощная архитектура. В основе — лёгкая, но гибкая архитектура на React + PostMessage, которая масштабируется и кастомизируется под любые нужды.
Лимитации? Пока не обнаружены. Инструмент активно тестируется в боевых условиях, и пока ни одной критичной лимитации замечено не было. Работает стабильно, как швейцарские часы.
Масштабируемость. Хочешь новый график? Фильтр? Отображение состояния Redux? Да легко. Благодаря React и открытой архитектуре, можно написать всё что угодно и куда угодно.
Лёгкий как перышко. Отчёт весит всего ~1MB — с историей, фреймом, графиками и всей аналитикой. Это значит:
1. Можно отправить в письме
2. Прикрепить в Allure
3. Выложить на GitHub Pages
4. Никаких громоздких снапшотов или HTML/PDF на 100MB.
Работа с реальным приложением, а не копией. Вы работаете с живым приложением во фрейме. Можно изменить состояние, перезагрузить и сразу увидеть изменения. Это не реплей, это реальность.
Максимальная скорость. Инструмент не тормозит тесты и не грузит страницу. Слой сбора покрытия — тонкий и быстрый. Отчёт генерируется мгновенно.
Простая настройка. Установка — это буквально:
1. Подключили скрипт
2. Собрали данные
3. Сгенерировали отчёт
4. Готово. Минимум усилий — максимум пользы.
Визуализация — уровень next. Мы не просто пишем тесты, мы видим, что происходит. Где кликнули, что проверили, где забыли — всё перед глазами.
Поддержка нескольких приложений. Может работать с несколькими доменами одновременно. Хотите — один отчёт, хотите — отдельные. Гибкость на максимум.
Легкая адаптация под любой стек. Инструмент настолько простой и прозрачный, что его легко перенести на любую платформу. Вот реализация на Python — а вот на TypeScript/JavaScript. Поддержка новых языков — вопрос желания, а не сложности.

ui-coverage-tool — это настоящий прорыв в области UI-автоматизации. Это инструмент, который не просто решает задачи, а меняет подход к тестированию.

Реально. Он:

Повышает прозрачность
Делает покрытие визуальным
Помогает писать осмысленные тесты
И, самое главное — вдохновляет развивать качество продукта

Очень рекомендую попробовать

В худшем случае — вы просто посмотрите, какие действия выполняются в ваших UI тестах. В лучшем — вы полностью переосмыслите, как подходите к UI-покрытию.

Весь исходный код инструмента вы можете найти на моем GitHub:

ui-coverage-tool — для Python
ui-coverage-tool-js — для TypeScript/JavaScript
ui-coverage-report — платформа для отчета
Пример HTML отчета

Теги:

Хабы: