Измерение покрытия UI тестами. Следующий уровень
Представьте: вы заходите в рабочий чат, а там коллега пишет — "Смотри, что я нашёл и прикрутил к нашим тестам! Кажется, у нас с покрытием беда." И кидает скриншот.
Естественно, у вас начинается внутренняя буря. Как? В смысле? Я пять лет клепал эти пять тысяч тест-кейсов, автоматизировал их с любовью и болью, а тут — «не всё покрыто»? Это что вообще за инструмент? Зачем ты мне это показал? Убери это немедленно. А потом вы просыпаетесь в холодном поту — вроде бы это был сон... но нет. Это реальность. И, возможно, даже к лучшему.
В этой статье я расскажу про ui-coverage-scenario-tool — новую версию инструмента, построенного на базе оригинального ui-coverage-tool. Первая версия уже была чем-то вроде прозрения: инструмент, который позволял впервые по-настоящему осознанно писать UI-тесты и видеть, что они действительно покрывают. Подробно про первую версию можно почитать вот тут.
Но сегодня не про прошлое, а про настоящее. Инструмент ui-coverage-scenario-tool — это всё та же основа, концепция и ядро, что и в оригинальном инструменте: измерение покрытия UI-тестами и наглядная визуализация. Но теперь — с совершенно новой суперспособностью: привязка покрытия к сценариям, тест-кейсам в TMS и даже к документации. Больше никаких абстрактных “эти элементы покрыты”, теперь всё по-взрослому: вот сценарий, вот шаги, вот что реально проверяется, а что — мимо.
Честно говоря, даже первая версия была эволюцией, и, скажем прямо, аналогов у неё не было и нет. А новая — ещё на голову выше. В ней появилось столько киллер-фич, что иногда самому страшно.
Короче, поехали. Будет интересно.
Зачем второй инструмент?
Хороший вопрос. Зачем вообще нужен ещё один инструмент измерения покрытия, если уже есть ui-coverage-tool, и он, черт возьми, классный? Он показывает покрытие тестами прямо на живом приложении — уже круто.
ui-coverage-tool прост в своей сути: он показывает, какие именно элементы на странице были задеты тестами. А дальше вы уже сами делаете выводы — где пробелы, какие проверки стоит добавить, где у нас "ну вот прям никто и не смотрел". Инструмент лёгкий, как перышко: обвязка на Python / TypeScript/JavaScript, быстрая интеграция, и отчёт — всё просто и прозрачно. Подключается куда угодно и как угодно. За пять минут — и вы уже видите, как ваши тесты реально работают.
А вот теперь на сцену выходит ui-coverage-scenario-tool. Он уже посложнее — как по отчёту, так и по интеграции. Но и возможности у него другие. Здесь в центре — сценарии. Каждый сценарий — это не просто "тест пошёл и кликнул", а последовательность действий, в которых участвуют элементы. То есть ui-coverage-scenario-tool — это следующий уровень. Он не просто показывает, что кнопка была нажата. Он показывает, в каком именно сценарии, в каком контексте, какие сценарии через неё прошли, и даже позволяет подсветить этот элемент прямо из сценария.
И да, есть связка с тест-кейсами, документацией, бизнес-требованиями — всё, чтобы видеть реальную картину: не просто "где кликали", а "зачем кликали и насколько это вообще важно".
Короче говоря:
ui-coverage-tool — лёгкий, удобный, быстрый, для базового покрытия и быстрой обратной связи.
ui-coverage-scenario-tool — продвинутый, более "умный", ориентирован на сценарии и бизнес-логику. Но и требует чуть больше усилий при внедрении.
Оба инструмента — нужны. Именно поэтому я не стал лепить из них Франкенштейна, а сделал два отдельных проекта. Потому что и задачи у них разные, и использовать их можно по-разному.
В чем суть
Главная фишка ui-coverage-scenario-tool — это не просто "покрытие UI", а покрытие в разрезе сценариев. Инструмент строит внятную хронологию действий, которую реально можно анализировать и использовать. Всё просто, как автоматизация логина:
Запустился тест — начало сценария
Пошли клики, заполнения, проверки — каждое действие сохраняется в JSON и привязывается к сценарию
Тест закончился — сценарий закрыт, данные зафиксированы
В результате мы получаем структурированную, удобную, и (не побоюсь этого слова) интеллигентную модель: сценарии → действия → элементы.
И, внимание, никакой черной магии. Никаких хаков, monkey patch-ей, инжектов в браузер, рефлексии и прочей боли. Просто логирование действий в JSON. Настолько тупо и просто, что работает идеально.
Минимальная обвязка, максимальная польза
Сборщик покрытий — это не какая-то сложносочинённая библиотека с миллионом зависимостей. Это тонкий слой, который можно интегрировать за 5 минут и не страдать. Он не ломает тесты. Он не влезает в ваш фреймворк. Он просто фиксирует, что вы сделали и когда.
И именно за счёт этого:
интеграция быстрая,
портирование на другие языки — плёвое: вот пример для Python, а вот для TypeScript,
производительность высокая — JSON-ки сохраняются почти AS IS, без постобработки.
Независимость отчёта
А теперь самое мощное: отчёт вообще не знает, на чём написаны ваши тесты. Он — самодостаточный. Загрузили в него данные + минимальные настройки — и всё, вы уже можете видеть, как работает покрытие.
Это даёт безумную гибкость:
Хотите писать тесты на Java + Selenium — пожалуйста
Используете Playwright на TypeScript — не проблема
У вас три команды с разными стеками? Все смогут работать с одним отчётом
А теперь главное: сценарный подход = новый уровень анализа
Мы не просто видим, какие элементы кто-то случайно затронул. Мы видим, какой сценарий зашёл на страницу, что он с ней делал, и можем:
найти пересечения между тестами,
понять, какие куски интерфейса никто не трогает,
и переосмыслить, как вообще у нас устроены тесты.
Это больше не просто "UI покрытие". Это сценарный интеллект нашей тестовой системы. Новый уровень. Новый стандарт.
Как выглядит отчёт?
Давайте без лирики — сразу к сути. Вся мощь и магия инструмента, конечно же, в его отчёте. И начнём мы именно с него.
Overview
В самом верху отчёта — несколько виджетов, дающих базовую информацию: настройки, графики, общее количество уникальных элементов, количество взаимодействий со страницей, и большой чарт с историей действий. Этот чарт — прям центр наблюдений: можно наглядно видеть, какие проверки выполняются, какие не трогались совсем, и как это меняется со временем. Удобно, чтобы отслеживать прогресс (или регресс).
Сценарии
Чуть ниже — сердце отчёта: интерактивный фрейм, в котором отображается сайт, и сайд-панель со списком сценариев. По умолчанию выбраны все сценарии — это значит, что на странице будут подсвечены все элементы, с которыми взаимодействовали тесты. Но если нужно — можно выбрать только конкретные сценарии и наглядно увидеть пересечения между ними.
Фреймом можно управлять:
фильтровать действия,
переключать настройки,
обновлять или очищать фрейм,
и даже скрыть сайд-панель, чтобы просто включить режим “показать все” и не отвлекаться на сценарии.
Погружение в сценарий
Дальше — ещё интереснее. Каждый сценарий можно открыть в деталях, и вот тут начинается настоящий кайф для тестировщика. Название сценария, ссылка на TMS, документацию или любую внешнюю систему — всё это можно указать. Это значит, что вы можете связать реальные шаги покрытия с бизнес-логикой.
Дальше — список шагов: Можно видеть, что делал тест. Но не просто “в логах” — при нажатии на иконку глазика рядом с шагом, в фрейме подсветится конкретный элемент, с тултипом: тип действия, локатор и всё, что нужно. Это не просто “шаги”, это — живое взаимодействие на реальном сайте, шаг за шагом. Прямо как дебаг, только в визуальной форме.
Каждый элемент в шаге — это:
тип действия (click, visible и т.д.),
номер шага,
локатор,
тип локатора.
И всё это можно фильтровать и искать: например, показать только шаги с кликами, или найти элемент по локатору.
А ниже — блок с статистикой по действиям в рамках сценария: сколько было кликов, сколько проверок видимости, и всё это ещё и наглядно в виде таблицы. А также чарт с историей действий в рамках сценария.
Детали по элементу: сразу всё и на месте
При нажатии на баджик рядом с элементом — открывается модалка с деталями покрытия. Что внутри?
Общая информация по взаимодействию с этим элементом,
И самое главное — список всех сценариев, которые хоть как-то с ним контактировали.
И вот это уже килер-фича. Потому что прямо тут видно: сколько сценариев “прошло” через элемент, кто с ним что делал, и можно быстро понять, где какие пересечения. Причём не надо лазить по спискам, искать сценарии вручную. Всё уже перед нами: кликнули по элементу → получили список сценариев → ткнули в любой → смотрим детали → если надо — прыгнули в TMS. Быстро. Удобно. И эффективно.
Фрейм — штука гибкая
В нём можно крутить и вертеть как хочешь:
Zoom — увеличивай/уменьшай масштаб фрейма. Особенно полезно, если смотрим мобильную версию или хочется отдалиться/приблизиться.
Цвета — меняются на лету. Если у нас сайт светлый, и подсветка не видна — просто берем и меняем цвета подсветки и баджиков. Настройки под себя — наше всё.
А теперь ещё одна киллер-фича — настройка контента внутри баджика. Инструмент позволяет наглядно видеть разные типы аналитики по элементу. Всё это доступно прямо в интерфейсе и включается в один клик:
Total number of actions — сколько раз вообще элемент трогали (клики, чеки, вся активность).
Total number of scenarios — сколько разных сценариев взаимодействовали с элементом. Например, если выбрали 3 сценария и 2 из них трогают одну кнопку — бум, у нас уже пересечение.
Total number of action types — сколько типов действий было по элементу (нажали, проверили видимость, и так далее).
Всё это настраивается без магии и костылей, прямо во фрейме. Включили нужное, получили аналитику, сделали выводы. Прямо как и должно быть.
Все остальное
Важно: все настройки — зум, фильтры, отображение, цвета и прочее — сохраняются автоматически. То есть один раз всё под себя настроили, и больше не надо каждый раз прокликивать заново. Настроили и забыли. Как и должно быть.
Ну и конечно, не обошлось без других вкусностей:
Быстрые и гибкие фильтры,
Поддержка тёмной темы — если мы не из этих любителей белых экранов,
Поддержка нескольких приложений одновременно — идеальное решение для распределённых команд, работающих с разными UI. Все тесты можно объединить в единый, наглядный отчёт,
И, что немаловажно — адаптивный и просто реально быстрый UI, который не тормозит даже на жирных отчётах.
Всё это вместе — делает отчёт не просто полезным, а по-настоящему удобным инструментом анализа, который хочется использовать.
Какие проблемы закрывает?
Кейсов может быть куча. Всё зависит от хотелок, бизнес-контекста и уровня фантазии. Но давайте по порядку. Вот где этот инструмент реально заходит на ура:
Анализ текущего состояния тестов
В голове у нас, конечно, всё красиво: "Да у нас всё покрыто, вообще всё, от и до!". А потом включаем отчёт и... бах — половина элементов даже не нюхала никакого теста. Ни разу. Никем. Никогда. Этот инструмент — прямой способ слезть с розовых очков. Каждый не покрытый элемент — это потенциальный "привет, баг, как дела?". И мы его либо увидим сейчас, либо потом словим в проде. Выбор за вами.
Обнаружение пересечений
Вот классика: два теста, вроде бы разные, называются по-разному, даже шаги чуть разные... А по факту делают одно и то же. Почему? Ну, кто-то "так сделал", кто-то "не знал", кто-то "копипастнул". Короче, если у вас тестов больше, чем пальцев на руках — шанс найти дубли просто запредельный. Именно здесь инструмент начинает светиться: показывает, кто где пересекается, и даёт шанс навести порядок. Ну или хотя бы перестать городить копии.
Понимание рисков при изменениях
Планируется рефакторинг страницы? Отлично. Открываем отчёт — а там на кнопку, которую хотят переделать, завязано 130 тестов. Сто тридцать, Карл! И мы уже не просто в панике, а конструктивно подходим к разработчику: "Слушай, если вы тут всё поломаете, у нас отъедет целый автопарк тестов. Давайте хотя бы data-test-id поставим, чтобы не откапывать потом это поле где-нибудь в error-логе CI." Согласитесь, гораздо эффективнее, чем ловить падения вслепую.
Ответы на “вечные” вопросы
Классическая сцена: врывается проджект с глазами по пять рублей и спрашивает —
"Слушай, а у нас поиск на главной точно тестируется? А фильтры? А сортировка? А вообще главная?" И мы вместо привычного "эээ… ну вроде да… где-то… наверное…" просто открываем отчёт, показываем элементы, сценарии, взаимодействия — и готово. Ответ не просто есть — он объективный, проверяемый и наглядный. И самое главное — никакой лжи себе и другим. Всё честно.
Осознанное тестирование (внезапно)
Будем откровенны. В 90% компаний автотесты — это про “лишь бы были”. В CI воткнули, галочка горит, все довольны. Вот только они ни на что особо не влияют. Инструмент ui-coverage-scenario-tool не спасёт ваши процессы, давайте честно. Но он покажет всю подноготную: какие тесты у вас есть, какие бесполезны, а какие вроде бы есть, но ничего не проверяют.
И мы внезапно узнаем, что у нас после создания сущности никто даже не проверяет, а действительно ли она появилась. Или что половина элементов на странице как стояли без внимания, так и стоят.
Прозрение? Да.
Поздновато? Тоже да.
Но лучше поздно, чем в проде с багом.
Ревью тестов без боли (и с пониманием)
Открываем MR: 1500 строк новых тестов. Прекрасно. Вдох. Выдох. Паника. Но вместо того чтобы вручную пытаться выудить смысл из каждой строчки, мы просто открываем отчёт покрытия и видим: что реально покрыто, какие элементы задействованы, какие сценарии отработали.
И вдруг всплывает "мелочь" — целый кусок новой страницы вообще никто не трогал. А ведь фича — жирная. Значит, забыли. Шанс упустить что-то важное? Без инструмента — 99%. С ним — уже можно работать головой, а не гадать по чайным листьям коммитов.
Доступность для бизнеса (да, серьёзно)
Часто ли ваш проджект или аналитик заглядывает в ваши отчёты по автотестам? Конечно же нет. И правильно делает — потому что отчёты скучные, непонятные и выглядят как распечатка из терминала 1995 года.
Но теперь — другое дело. Вместо унылого текста "кликаем туда, вводим это" — интерактив, визуализация, живая карта покрытия. Можно не просто прочитать, а потрогать, посмотреть, понять. И, внезапно, у бизнеса появляется идея: "А почему вы не тестируете вот этот фильтр? Мы же на нём теряем половину конверсии!" То есть, внимание: бизнес сам хочет тестов. Не мы их уговариваем — они приходят к нам.
Обоснование перед бизнесом
Типичная история:
— Мы хотим редизайн.
— Окей, но там 130 тестов завязано.
— Это сколько?
— 130.
— А это много?
— Ну, это типа дофига.
— Ага.
С отчётом всё иначе. Показываешь красиво: "Вот страница, вот 130 тестов, вот интерактивная карта, вот куда они жмут". И сразу видно: если редизайнить, то всё отвалится. Не навсегда, но временно. И мы не побираемся с аргументами — мы показываем. Хотите редизайн? Делайте. Просто заложите время, потому что вот наглядно видно — будет боль. И да, иногда отчёт говорит сам за себя настолько убедительно, что тебе даже рот открывать не надо. Всё понятно и так.
Развитие тестовой культуры (ну а куда деваться)
Как объяснить команде, что ваши автотесты — это не просто «магия в CI», а реальная защита продукта? Показать отчёт. Пусть фронтендеры увидят: вот, их компонент покрыт, вот сюда жмут, а вот сюда — никогда. И сразу пойдёт в ход:
— «Давайте добавим тест!»
— «А может я тебе data-test-id расставлю?»
— «О, у нас сценарий на этот попап забыт!»
Короче, видимость рождает понимание. А понимание — уважение. И мы из "того чела, который тесты пишет" становимся партнёром, который помогает всей команде не падать в баги лицом.
Использование на ретро (да, отчёт тоже может туда ходить)
Вот собрались вы на ретроспективу, и опять звучит классика:
— «У нас баг выехал в прод, как так вышло?»
— «Ну, мы же вроде тестировали…»
— «А где тестировали?»
— «Ну… где‑то… наверно…»
А тут мы достаём отчёт — как карту поля боя: «Смотрите. Вот фича. Вот 24 элемента. Вот что покрыто, вот что нет. А вот баг — ровно в том месте, где тестов 0.» Моментальная ясность. Никаких «вроде», только факты. И сразу разговор переходит из «кто виноват» в «что улучшим». Так что да, отчёт может делать ретро честнее и полезнее, и на всякий случай — нагляднее, чем стикеры на доске.
Планирование (а вот это прям must-have)
Когда вы планируете спринт и решаете, что тестировать, что покрывать, а где можно и на проде посмотреть, теперь у вас есть не просто “чуйка” или “на глаз”, а реальные данные.
Открываете отчёт — и вот:
Тут 80% сценариев уже есть — можно не трогать.
Тут дыра — вообще никто не кликает по фильтру.
Тут 20 сценариев делают одно и то же — может, пора почистить?
Больше не нужно спорить «где тонко» — теперь это видно. А если кто‑то скажет «зачем писать ещё тесты?», можно просто повернуть экран и сказать: «Вот. Тут. Пусто. Всё ещё не надо?». Короче, отчёт превращает планирование в нормальный инженерный процесс, а не в «угадай, где больно».
Онбординг новых людей
Представьте: пришёл новый автоматизатор. Вы ему говорите: «У нас тут 1500 тестов, 60 фич, куча компонентов, давай, вливайся.». Его реакция:...
А теперь представьте другую сцену: вы открываете UI coverage-отчёт, показываете одну страницу — и за 2 минуты человек понимает:
что уже покрыто,
что часто используется,
где дыры,
и где можно сразу влиться и сделать вклад, а не ковыряться неделями в чужом коде.
Вывод? Инструмент —это ещё и навигатор для новичков. Не просто «читай документацию», а «вот визуальная карта тестовой вселенной».
Переосмысление автотестов
А теперь на философском уровне. Инструмент заставляет по-новому взглянуть на автотесты. Не как на строчки кода, которые “ну вроде бы что-то проверяют”, а как на живые сценарии, которые реально ходят по интерфейсу, трогают кнопки, читают текст, влияют на продукт.
И когда ты видишь это визуально, когда ты можешь ткнуть в каждый элемент и понять — кто, когда и зачем его трогал — у тебя появляется желание писать тесты не для отчётности, а для пользы.
Это не просто инструмент для тестов — это зеркало того, как работают ваши тесты. И, возможно, лучший способ понять, где вы как команда теряете контроль.
Как использовать?
Всё максимально просто. Инструмент можно использовать в любом фреймворке и на любом языке. В примерах ниже будет Python, но под TypeScript/JavaScript тоже всё готово — вот пример для JS/TS. Если пишете на чём-то своём — не проблема, обвязка тривиальна и пишется за вечер.
Шаг 1. Установка
pip install ui-coverage-scenario-toolШаг 2. Настройка
Подробная инструкция по конфигурации — в документации, но по сути всё сводится к одному параметру.
Например, настройка через .env может выглядеть вот так:
UI_COVERAGE_SCENARIO_APPS='[
{
"key": "ui-course",
"url": "https://nikita-filonov.github.io/qa-automation-engineer-ui-course/#/auth/login",
"name": "UI Course",
"tags": ["UI", "COURSES"],
"repository": "https://github.com/Nikita-Filonov/qa-automation-engineer-ui-course"
}
]'И всё. Это обязательный минимум. Остальные переменные — опциональны, и чаще всего трогать их не нужно. По умолчанию всё работает из коробки.
Шаг 3. Использование
После настройки инструмента можно использовать его прямо внутри тестов. Ниже — базовый пример с использованием Playwright и отслеживанием действий пользователя:
from playwright.sync_api import sync_playwright
# Импортируем основные компоненты инструмента:
# - UICoverageTracker — главный класс для отслеживания покрытия
# - SelectorType — тип селектора (CSS, XPATH)
# - ActionType — тип действия (CLICK, FILL, CHECK_VISIBLE и т.д.)
from ui_coverage_scenario_tool import UICoverageTracker, SelectorType, ActionType
# Создаём экземпляр трекера.
# Значение `app` должно совпадать с ключом из переменной UI_COVERAGE_SCENARIO_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")
# Начинаем сценарий:
# - url: ссылка на тест-кейс в TMS или документации
# - name: человеко-понятное название сценария
tracker.start_scenario(
url="http://tms.com/test-cases/1",
name="Successful login"
)
# Взаимодействие с input логина
username_input = page.locator("#username-input")
username_input.fill('user@example.com')
# Отмечаем это действие в покрытии
tracker.track_coverage(
selector='#username-input', # Селектор элемента
action_type=ActionType.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"]',
action_type=ActionType.CLICK,
selector_type=SelectorType.XPATH
)
# Завершаем сценарий — сохраняем все собранные данные
tracker.end_scenario()Использование через фикстуру (лучше для реальных проектов)
На практике начало и конец сценария удобно выносить в pytest-фикстуру:
from typing import Generator, Any
import pytest
from playwright.sync_api import Page
from ui_coverage_scenario_tool import UICoverageTracker
from pages.authentication.login_page import LoginPage
# Фикстура для трекера покрытия UI
@pytest.fixture
def ui_coverage_tracker(request) -> Generator[UICoverageTracker, Any, None]:
tracker = UICoverageTracker(app="ui-course")
# Начинаем сценарий: название берём из имени теста
tracker.start_scenario(url=None, name=request.node.name)
yield tracker
# Завершаем сценарий после выполнения теста
tracker.end_scenario()
# Фикстура, возвращающая страницу логина с трекером внутри
@pytest.fixture
def login_page(page: Page, ui_coverage_tracker: UICoverageTracker) -> Generator[LoginPage, Any, None]:
return LoginPage(page, ui_coverage_tracker)
Далее можно использовать внутри PageObject:
from playwright.sync_api import Page
from ui_coverage_scenario_tool import UICoverageTracker, SelectorType, ActionType
class LoginPage:
def __init__(self, page: Page, tracker: UICoverageTracker):
self.page = page
self.tracker = tracker
self.username_input = page.locator("#username-input")
self.password_input = page.locator("#password-input")
self.login_button = page.locator("//button[@id='login-button']")
def fill_username(self, value: str) -> None:
self.username_input.fill(value)
self.tracker.track_coverage(
selector="#username-input",
action_type=ActionType.FILL,
selector_type=SelectorType.CSS
)
def fill_password(self, value: str) -> None:
self.password_input.fill(value)
self.tracker.track_coverage(
selector="#password-input",
action_type=ActionType.FILL,
selector_type=SelectorType.CSS
)
def click_login(self) -> None:
self.login_button.click()
self.tracker.track_coverage(
selector="//button[@id='login-button']",
action_type=ActionType.CLICK,
selector_type=SelectorType.XPATH
)
А если вы вдруг проснулись сегодня с особенно изощрённым желанием всё автоматизировать — можете сделать кастомный маппинг, который будет сам вытаскивать ID тест-кейса из воздуха (или из TMS, если повезёт). В общем, ограничений здесь никаких: хотите — делайте как удобно, хотите — как неудобно, лишь бы работало. Фантазия — единственный лимит.
Если хочется прям пример с претензией на элегантность — добро пожаловать в статью, где мы аккуратно интегрировали всё это безумие с PageFactory. Главное, не забудьте:
До теста — запустить сценарий,
После теста — завершить сценарий,
Внутри теста — трекаем действия.
А дальше — как вашей душе угодно и как вписывается в ваши процессы. Хотите руками, хотите в хуках, хотите через проклятия и шаманские пляски — инструмент справится.
Шаг 4. Отчет
После прогона тестов в папке coverage-results появятся файлы с результатами покрытия. Лезть туда руками, что-то править или дописывать — не надо. Всё уже готово. Чтобы сгенерировать отчёт — выполняем одну единственную команду:
ui-coverage-scenario-tool save-reportПосле этого у вас появляются три артефакта:
index.html— сам отчёт, красивый, интерактивный, прямо в браузере открывается;coverage-history.json— история покрытия;coverage-report.json— машинно-читаемый отчет, можно закинуть в лог или в дашборд CI/CD.
На этом всё. С точки зрения автотестов вы свободны как ветер. Установили, подключили, настроили — и отдыхаете. Особенно круто работает в связке с PageFactory — покрытие ложится туда как родное. Очень советую заглянуть вот в эту статью — там про это подробно.
Шаг 5. Агент
Но есть один нюанс. Если вы думаете, что после генерации отчёта он прям сразу начнет показывать покрытие поверх страницы — расслабьтесь, такого чуда не будет. Чтобы покрытие отображалось на сайте, нужно встроить один маленький агент в HTML. Делается просто:
<script src="https://nikita-filonov.github.io/ui-coverage-scenario-report/agent.global.js"></script>Вот и всё. Добавили — работает. Безопасно ли это? Ну, во-первых, да. Во-вторых, весь код открыт. Не доверяете? Форкните, скачайте себе агент, проверьте, перезапеките — делайте что угодно, лишь бы вам спалось спокойно. Хотя если вы подозреваете вредоносное ПО в скрипте, который трекает click, может, вам стоит удалить ещё и Google Analytics, Яндекс Метрику, Bootstrap, React DevTools, Hotjar и прочих «шпионов».
А если серьёзно — скрипт минимальный, ничего никуда не отправляет, работает локально и делает одну задачу: показывает вам, что тест реально делал на странице. Всё.
Почему это уникально?
Ну, хотя бы потому что такого раньше просто не было. Серьёзно. Это первая (и пока что единственная) попытка в сторону настоящей эволюции измерения покрытия UI-тестами. Если угодно — первая ветвь на дереве, которое только начинает расти.
Да, кто-то что-то когда-то пробовал. Но обычно всё упиралось в странные реализации, тяжёлые снапшоты, боль при настройке или полную невозможность адаптировать под реальный проект или разные фреймворки. А потом всё это благополучно отправлялось в архив на GitHub под меткой no longer maintained.
А тут — просто HTML-файл. Открывается на чём угодно: GitHub Pages, GitLab Pages, Allure, прямо из IDE или с десктопа. Хотите — запускайте хоть на микроволновке с поддержкой браузера. Весит от 800 КБ до 1.1 МБ. То есть для визуального отчёта — почти пушинка.
Вместо тяжёлых снапшотов по 10 MB, как это модно в старших кругах, инструмент работает напрямую со страницей. Под капотом — протокол postMessage, поэтому элементы на странице подсвечиваются почти мгновенно. И никаких танцев с бубном: открыл сайт, открыл отчёт — и вуаля, всё живое, всё интерактивное.
Плюс — он не привязан ни к чему вообще. Ни к фреймворку, ни к языку, ни к структуре проекта. Хотите обвязку на Python — пожалуйста. Предпочитаете TypeScript — тоже есть. Используете Rust, Bash, Excel с макросами? Неважно. Главное — чтобы вы могли сохранить JSON и добавить скрипт на страницу.
Вот тут будут ссылки на готовые обвязки:
Этот инструмент — не импровизация на коленке, а результат нескольких сотен экспериментов, фейлов, проб, боли, отчаяния и наконец — здравого смысла. Смотрел на снапшоты, на скриншоты, на плагины, на внутренности других тулов... и в итоге сделал то, что просто работает.
Если где-то и есть что-то похожее — дайте знать, я искренне хочу посмотреть. Но, спойлер: пока не встречал ни одного решения, которое одновременно:
работает сразу,
не заставляет менять архитектуру проекта,
и вообще не зависит от языка, фреймворка или «модного стека года».
Почему это лучше, чем то, что есть сейчас?
Начнём с простого: а что вообще есть сейчас? Обычно — ничего. Ну вот прям совсем. UI покрытие? Где? Кто? Когда? Тишина. Тесты вроде есть, UI вроде есть, но как это всё между собой связано — уже загадка.
Иногда, конечно, кто-то из лучших побуждений прикручивает TMS. Красиво, формально, по-взрослому. Только вот проблема: TMS показывает то, что мы сами себе придумали. Условный пример: у нас 100 тест-кейсов, из них 70 автоматизировано. Ура, 70% покрытия! Осталось автоматизировать 30, и будет целых 100%. Победа?
Ну, не совсем. Потому что эти 100 кейсов мы придумали сами. А если бы действительно описали всё поведение интерфейса, то их могло бы быть 500. Или 1000. То есть фактическое покрытие — не 70%, а 7%. Просто считать это не очень удобно, особенно когда хочется красивые графики в отчёте.
А теперь зайдём с другой стороны. Допустим, у вас продвинутый процесс: никаких ручных кейсов, только автотесты. Что тогда? Тогда у вас всегда 100% покрытия. Потому что считать больше нечего. Вот он — полный контроль... над своим воображением.
Проблема в том, что всё это — про кейсы, а не про реальное поведение системы. TMS никак не связана с интерфейсом. Она не знает, с какими кнопками работали тесты, какие поля реально трогались, какие сценарии запускались. В худшем случае — вы вручную прописали шаги. В лучшем — шаги добавились автоматически, и теперь их страшно читать.
А теперь внимание: ui-coverage-scenario-tool (как и его предшественник ui-coverage-tool) показывает реальное покрытие. Не гипотетическое, не «по документам», а на настоящем интерфейсе, на живом проекте. Прямо в браузере, визуально, красиво и прозрачно.
И ещё один момент, который хочется обводкой, жирным и капслоком — актуальность. Изменился UI? Ок, запустили тесты заново — и у нас новое покрытие. Не надо руками ничего обновлять, не надо в TMS заходить и добавлять новый шаг. Потому что как только вы забыли это сделать — всё, покрытие устарело, доверие потеряно, метрика умерла. А мёртвые метрики, как известно, только места в отчётах занимают.
В итоге
Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.
ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».
Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.
Вопрос не в том, нужно ли вам измерять покрытие. Вопрос в том, хотите ли вы знать правду.
Весь исходный код инструмента вы можете найти на моем GitHub:
ui-coverage-scenario-tool — для Python
ui-coverage-scenario-tool-js — для TypeScript/JavaScript
ui-coverage-scenario-report — платформа для отчета