Благодарю за столь эмоциональный и многословный комментарий. Видно, что мой скромный инструмент задел вас за живое, и это уже успех.
Ваш развернутый поток сознания заслуживает уважения — не каждый день можно увидеть столько страсти при обсуждении вопроса о покрытии UI. Особенно приятно, что вы нашли время написать целую стену текста, демонстрируя глубину боли, которую, судя по всему, моя работа вам причинила.
Теперь по сути:
Я рад, что вы открыли для себя различие между действиями и проверками. Поверьте, большинство людей в индустрии догадываются об этом даже без 5-страничных манифестов.
Касательно старых конференций, no-name решений и 19 минут на ознакомление: Удивительно, сколько презрения можно вложить в слова о событиях, о которых вы сами не так много знаете. К слову я лично был на этой конференции еще несколько лет назад и был в курсе про данное решение еще до того, как вы про него узнали. Не стесняйтесь, признание — первый шаг к принятию.
Ваше объяснение разницы между документацией, тест-кейсами и фактическим тестированием трогает своей наивностью. Вероятно, вы и вправду считаете, что TMS и красивые таблички спасают от багов в продакшене. Желаю удачи в этой вере.
Что касается "старых технологий" и морали пяти лет назад: Спасибо, что напомнили, что инновации для вас — это плохое слово. Видимо, в вашем мире рефакторинг под GO решает вопросы качества продукта лучше, чем инструменты контроля реального поведения тестов. Потрясающая логика.
По поводу отсутствия ассертов: Инструмент и не претендует на роль экстрасенса. Я не строю иллюзий, что могу угадать мысли тестировщика через отслеживание кликов. В отличие от некоторых, кто, судя по вашему тону, всерьез считает, что TMS отражает реальность тестирования.
В завершение хочу сказать: Если в будущем вам вновь захочется выплеснуть поток токсичности и обид за жизнь, не стесняйтесь — я рад видеть, что мой инструмент вызывает живые эмоции. А значит, он работает.
P.S.: Вместо скриншот-тестирования, как вы опасались, я, пожалуй, займусь еще одним полезным делом — выведу "coverage-психотерапию" в отдельную ветку разработки. Успех будет гарантирован — аудитория уже есть.
Вы потратили столько времени на комментарий, что видно — тема действительно вас зацепила. И это хорошо: значит, я попал в настоящую боль индустрии. И видимо, потому что в реальности всё не так радужно.
Теперь к сути.
Да, идея трекать взаимодействия с UI не нова. Новый сам подход, делать это не через костыли и плагины в браузере. И нет, наличие старой статьи на Хабре не делает её реализацией ни массовой, ни удобной, ни применимой в реальных проектах. Потому что старая статья есть, но никто этим не пользуется.
Если бы всё было так идеально, как вы описываете с TMS и ручным линкованием тестов, в реальных компаниях не стоял бы вопрос:
«А что реально покрыто?»
«Где дырки в UI?»
«Почему баги всплывают на очевидных сценариях?»
TMS — это документация. Мой инструмент — это факт.Документация не показывает реальное поведение тестов на фронте. Никогда.
TMS показывает, что ЗАДУМАНО тестировать.
Мой инструмент показывает, что ФАКТИЧЕСКИ тестируется.
Хотя странно: если у вас всё настолько идеально через TMS, ручные тест-кейсы и процессы — зачем вы вообще читаете статьи про современные методы контроля покрытия?
Если по-честному — ваш подход морально устарел лет на пять.
Сегодня в реальных проектах автотесты пишутся сразу, без бумажной прослойки в TMS. Контроль покрытия — это не вера в чекбоксы в тест-менеджменте, а проверка реального поведения UI. Я понимаю, что хочется защищать старые процессы — в них вложено много сил. Но мир меняется. И если вам кажется, что инновации не нужны — это не значит, что они не работают.
Вы продолжаете говорить про процессы, как будто они волшебным образом решают всё. На практике процессы часто расходятся с реальностью, и я предлагаю инструмент, который это видно делает.
Мой инструмент показывает то, чего не видно в TMS:
Какие элементы реально затронуты тестами.
Какие остались без внимания.
Какие части UI "мертвым грузом" висят без тестового покрытия.
Если вы не видите в этом ценности — отлично. Это просто значит, что у вас другие задачи или другие масштабы. Но это не значит, что проблемы не существует.
И уж точно это не делает ваш комментарий чем-то большим, чем очередной спич в стиле "раньше было лучше". Мир меняется. Инструменты тоже.
P.S. Критиковать легче, чем создавать. Спасибо, что своим комментарием подчеркнули, что в отрасли по-прежнему нужен новый взгляд на проблему.
Если тесты мешают друг другу при запуске под одним пользователем — это уже первый красный флаг. Значит, между ними есть нежелательные зависимости, и они не изолированы. А это не баг, а фича плохого дизайна тестов/тестового фреймворка.
В идеале каждый тест должен работать в "песочнице": свои данные, своя сессия, никакой пересечки. Это достигается, как описано в статье, с помощью грамотно написанных фикстур, которые поднимают всё необходимое под капотом и изолируют окружение.
Но да, бывают случаи, когда тесты вынужденно гоняются под одним и тем же юзером — например, если у тебя пул аккаунтов ограничен. Тогда в ход идёт pytest.mark.xdist_group. С ним можно сгруппировать тесты, которые не могут идти параллельно, и они будут исполняться в одном воркере, последовательно. Остальные при этом запустятся параллельно — и ты не жертвуешь всей скоростью.
Но это — скорее "аварийный выход". Основной путь — делать независимые и изолированные тесты. Тогда и таких вопросов не возникнет
Что вы делаете с авторизацией при параллельном запуске? Вы же не можете два теста запустить с логином под одним пользователем, иначе они будут мешать друг другу.
Спасибо за комментарий! А про параллельное выполнение тестов уже описывал в статье по API тестам, для UI тестов отличий никаких. Все решается установкой библиотеки pytest-xdist и добавлением флага --numprocesses {number_of_workers} к команде запуска
До сих пор я лично пользуюсь матрицей трассировки в xlsx-формате, которая генерируется автоматически на основе двух csv-таблиц. Csv-шки заполняются уже вручную.
Матрица трассировки через CSV/XLSX — действительно очень распространённый и рабочий подход, особенно когда важна формальная связка требований и тестов. Вижу такое решение как классическую проверенную практику. Главный минус, как по мне, это необходимость ручной поддержки и человеческий фактор
В свою очередь, стараюсь минимизировать ручной труд, особенно в UI-части — хочется, чтобы покрытие можно было буквально “увидеть глазами”. И, конечно, чтобы всё обновлялось автоматически: один раз настроил — и дальше просто пользуешься.
Вы абсолютно правы в одном: любой отчёт, будь то Allure, отчет в CI, Excel или визуализация покрытия — нужно смотреть глазами и интерпретировать. Это не чип в голову, который сам всё объяснит — и, по-хорошему, он таким быть не должен.
Но тут как раз и появляется важный момент: возможность увидеть то, что иначе ты бы не заметил.
В случае с UI-покрытием это особенно важно — потому что элемент может "быть на странице", но никогда не покрываться ни одним тестом. И, к примеру, продакт может в любой момент спросить: "А у нас поиск вообще тестируется?" — и не получить чёткого ответа. А с таким отчётом ты просто открываешь страницу — и сразу видно, что покрыто, что нет.
Бизнесу это может быть нужно не в формате: "дайте мне отчёт", а в формате: — а почему у нас на проде отвалился фильтр, вы же это тестируете? — ммм... ну, не совсем... И тогда такой отчёт — это буквально спасение.
Возможно, в статье стоило отдельно выделить раздел с примерами кейсов, чтобы это было понятнее. Добавлю
Спасибо за комментарий! Да, тут скорее про python было, думаю если бы был JS/TS, puppeteer однозначно можно было бы упомянуть, как например тот же cypress
Спасибо за вашу активность, давайте по порядку, спокойно, без эмоций:
Не видим, смотрим через замочную скважину
Вы сами себе противоречите: сначала говорите "мы ничего не видим", потом — "всё равно ничего не покрыто". Так может как раз и видим? Инструмент показывает то, что реально отрисовано, и в этом его сила. Он не гадает по облакам, он даёт фактическую картину.
Уличил во лжи / яйца / признание
Оставлю это без комментариев — не мой стиль мериться органами. Я тут про продукт и про факты, не про уличные перепалки с гопниками.
Контрибьюшен открыт
Вот тут вы сами ответили на свой же тезис: инструмент открыт, адаптируем, обсуждаем. Нравится идея — welcome, сделайте лучше. Вместо того, чтобы пытаться ткнуть пальцем, можно просто поучаствовать. Это не сарказм — это прямое приглашение.
Выбрали неправильную стратегию общения
Наоборот. Я с самого начала говорил: критику принимаю, если она идёт в связке с предложением или решением. Кричать "это всё фигня" — легко. Сделать PR — вот это польза.
100кб в прыжке / мусор
Отчёт содержит графики, хронологию действий, снимки, динамику. Это не hello-world.json.
Да, он весит чуть больше, чем «проверка одного чекбокса», потому что он визуальный и подробный. Если он показывает что покрыто, как, когда и кем — 1MB за это более чем уместно.
Старые отчёты показываются с новым приложением
Показываются. Потому что это — история. Как работали тесты тогда, что покрывали тогда. Это и есть point-in-time snapshot. Хочешь актуальное — запускай тесты заново и получишь актуальный отчёт. Всё честно.
Инструмент не претендует на всемирное господство. Он закрывает свою задачу — понятно, наглядно и прозрачно показать покрытие UI. Не вместо, а в дополнение.
Если вы это не видите — возможно, это просто не ваш кейс. Такое тоже бывает.
Но инструмент есть, он работает, и он реально помогает.
P.S. И да, если вы увидели всего 1% — возможно, пора протереть глаза и посмотреть шире.
Про безопасность и X-Frame-Options Да, в корпоративной среде есть ограничения, и они реальны. Но если подходить с таким критерием, то давайте вычеркнем и весь open source, который не покрывает 100% корпоративных кейсов. А это — почти всё.
На dev/stage можно отключить заголовки, можно поднять отчёт рядом, можно подгружать снимки и визуализировать отдельно. Это не проблема, это просто нюанс интеграции. У инструмента есть фокус — визуализировать покрытие UI, и он с этим справляется. Даже в корп-среде.
Про веру и максимализм Я действительно верю в свой инструмент — потому что я его сделал. С нуля. Один. И он работает, этим пользуются, он приносит реальную пользу — это факт, а не эмоция.
Если у вас есть альтернатива — давайте посмотрим. Я открыт к конструктиву, но обсуждать "как должно быть" проще, чем сделать "как есть". Поэтому я привык слушать тех, кто тоже делает.
Про скрипт и безопасность Любой скрипт можно форкнуть и держать у себя, как делают с Bootstrap, jQuery, любой CDN. Никто не заставляет подключать агент напрямую. Это инструмент, а не вирус. Исходники открыты — берите, собирайте, адаптируйте под себя.
P.S. И про минус — да нет, это не яXDЯ в дискуссии за факты, не за кнопки.
Если коротко: инструмент не идеален, но он реален. Он уже решает задачи. А что-то, что "могло бы быть лучше", — ну так сделайте, покажите. Я первый скажу "круто".
"Когда ты сделал что-то своё, а тебе говорят, что оно 'неподходит под корп. среду'"
"На одном экране видно хорошо если 1% от того, что реально надо покрыть тестами, а до остальных ещё добраться надо."
Вы описали не проблему инструмента, а проблему отсутствия нормальных тестов. Инструмент ничего не скрывает — он показывает то, что реально трогают автотесты. Остальное не покрыто? Ну вот, теперь мы это видим. Добро пожаловать в реальность.
"Ой, лимитации."
Да, звучит как будто вы прям расстроились, что не нашли критичных проблем. Но ничего, держу в курсе — инструмент будет развиваться, и багтрекер открыт. Можете оставить фидбек, если вдруг появится что-то конкретнее, чем "ой".
"Что мешает поддержать фреймворки, которые не рендерят весь DOM в тестах?"
Ничего не мешает. Просто этот инструмент для визуального UI, а не для фантомных абстракций. Хотите интеграцию с виртуальными компонентами — флаг в руки, контрибьюшен открыт. Сделаете PR — я скажу спасибо и залью.
"Много/мало определяется не годом, а соотношением полезной информации к бесполезной."
Именно. 1MB отчёта — это:
история действий,
интерактивный фрейм,
таймлайны,
подсветка элементов,
и вся аналитика.
Если вы считаете это "бесполезным", возможно, вам просто пока не приходилось разбираться с рефакторингом тестов и анализом покрытия.
"Старые отчёты превращаются в тыкву"
Старые отчёты отражают то, как работали тесты тогда. Новый релиз — новые тесты. Захотел — пересобрал. Это не минус, это индикатор жизни проекта. Только мёртвый проект не меняется и не ломает покрытие.
Этот инструмент не решает все беды мира — зато он даёт реальный визуальный фидбек, без симуляций и фантазий.
Проблемы в UI-тестировании — это не "у нас слишком много вьюшек", а "у нас нет ни одного нормального инструмента, чтобы понять, что реально протестировано".
"В реальном приложении много вьюшек, которые с ходу не видны"
Сюрприз: именно поэтому инструмент и нужен. Чтобы увидеть, что реально покрыто, а что забыто. Он не заменяет здравый смысл или хороший тест-дизайн, он показывает фактическое покрытие. Это зеркало, а не костыль.
"React — не от хорошей жизни"
Инструмент работает, потому что архитектура простая и гибкая, а React идеально ложится под визуализацию и расширение через postMessage. Можно не любить React, но это не мешает инструменту быть полезным и кастомизируемым.
"DOM не рендерится, ничего не подсветите"
Если DOM не рендерится — значит, там и не с чем работать визуально. Это как жаловаться, что тепловизор не показывает невидимое. Этот инструмент не для всего подряд — он для UI, который реально отрисовывается.
"1MB — многовато"
Серьёзно? У нас в 2025-м отчёт весом 1MB — это уже много? Это как жаловаться на размер скриншота. Там графики, история, фрейм, интерактив — не просто текстовичок на коленке.
"Что будет, когда данные обновятся?"
Ну… появятся непокрытые зоны. Это как раз плюс — вы сразу видите, где тесты устарели. Инструмент и не должен хранить вечную истину, он показывает текущее покрытие. Как бы если данные обновятся, то и тесты попадают. Чиним тесты, запускаем, видим новую картину покрытия.
Фишка в чём: этот инструмент — не панацея, не silver bullet. Это визуальный инструмент, который реально помогает понять, что происходит в UI.
Никто до меня это не делал на таком уровне — и если у вас есть что-то лучше, покажите. Я первый в очереди на то, чтобы посмотреть и сказать «вау».
Про iframe и X-Frame-Options — вы абсолютно правы: современные сайты, особенно корпоративные, действительно часто блокируют загрузку во фреймы, и это абсолютно оправданная мера против кликджекинга. Однако, инструмент ui-coverage-tool не предполагает работу с продакшеном напрямую, даже специально написан про это в статье. Он ориентирован на тестовые стенды, локальные версии и dev-сборки — там, где у разработчика/тестировщика есть контроль над конфигурацией.
То есть, да, X-Frame-Options может мешать — и это нормально. Но в CI или при ручной проверке такой механизм работает идеально и дает визуальную обратную связь прямо на живом UI — что и было главной целью. Так что всё честно и реалистично в рамках применения.
Насчёт скрипта agent.global.js — это абсолютно резонный пойнт. Да, я бы тоже не стал подключать любой внешний скрипт в продакшн без ревью. Поэтому в статье прямо указано: использовать только на тестовом окружении.
Плюс исходники полностью открыты: любой желающий может собрать агент вручную, посмотреть, как он работает, и адаптировать под свои нужды. Этот проект — не blackbox и не магия, а прозрачный инструмент, созданный разработчиком для разработчиков.
И если уже совсем паранойя, можно взять сделать форк/утащить себе локально и уж точно никто туда не вмешается
Про «идея не нова» — возможно, но я пока не встречал инструмента, который делает это именно так:
без необходимости менять код приложения,
без зависимости от конкретного фреймворка,
с визуализацией поверх живой страницы
и с возможностью отслеживать реальные действия из автотестов. Если знаете аналог — с удовольствием посмотрю, будет интересно сравнить подходы. А пока — это первая публичная реализация такого рода с открытым исходным кодом
Как формируется полный URI для запросов в HTTPX? Вижу base и вижу эндпойнты отдельно.
Когда мы формируем Client мы можем передать в качестве аргумента base_url. При использовании Client для выполнения запросов, полный URL будет формировать автоматически "под капотом" httpx. Например:
# Указываем base_url при инициализации клиента
client = httpx.Client(base_url="http://localhost:8000")
# Теперь при выполнении запроса можем указывать только маршрут эндпоинта
# HTTPX сам сформирует полный URL под капотом
# base_url + endpoint => "http://localhost:8000/api/v1/users"
client.get("/api/v1/users")
Валидация ответов json-схемой. Почему не тем же расхваленым pydantic?
Можно делать и через pydantic. По факту валидация через Pydantic уже выполняется, например тут
Pydantic действительно проверяет структуру данных и выдаст ошибку, если каких-то обязательных полей не будет. Однако у него есть один нюанс: он автоматически преобразует данные, если они пришли не в том формате. Например, если ожидается поле number: int, а в JSON пришло "number": "100" (строка), Pydantic без ошибок преобразует строку в число.
Да, начиная с Pydantic v2, в метод model_validate_json можно передать strict=True, чтобы включить строгую проверку типов:
my_model = MyModel.model_validate_json(data_json, strict=True) # Ошибка, если типы не совпадают
Но у этого подхода есть недостатки:
Нужно каждый раз явно передавать strict=True, что может быть забыто.
Можно создать кастомную базовую модель, которая всегда включает strict=True, но это усложняет проект. Даже если сделать кастомную модель, то у вас уже будет два метода: один из Pydantic для валидации модели из JSON, а второй ваш кастомный, и придется постоянно держать это в голове. А если придет новичок, то он точно про это не узнает.
В итоге более надежное решение —
Использовать Pydantic для работы с данными (преобразование JSON → объект Python).
Использовать jsonschema для строгой проверки схемы.
Кроме того, вынесение проверки JSON-схемы в отдельную функцию позволяет:
Легко добавлять логирование и шаги Allure.
Гарантировать, что валидация всегда выполняется правильно.
Добавление Allure шагов и логирования на уровень методов pydantic, как будто идиоматически неверное решение
Вызвало чувство глубокой брезгливости, но постарался успокоится, может часный случай... а потом понял - нет, у них это в норме
Как говорится если что-то плавает, как утка, выглядит как утка, крякает, как утка, то это утка)
А тоже было много слов про "вайб" и "софт скилы" и т.д.
Это все пустое, как по мне, в этом больше лицемерия, чем вайбов и софт скиллов. Скорее умение улыбаться, когда кого-то или даже тебя поливают грязью, но! Называют это критикой.
При этом если тебе не нравится эта критика или ее дает человек не компетентный, то скажут, что ты токсик и не умеешь воспринимать критику. Критика это хорошо, но только если меня будет критиковать любой бродяга с улицы, то пожалуй это будет не лучшая критика. Также и тут
Создание иллюзии дружелюбности в команде/компании, когда коллеги в чатах чуть ли не горло готовы друг другу перегрызть
Софт скиллы это скорее про умение договориться с кем угодно, о чем угодно, а не про полировку пятой точки начальству
Короче грустные вайбы, одно радует - так не во всех компаниях/командах
Всё так. Это заворачивается в красивую обёртку, подаётся под соусом «у нас модный процесс», где каждый QA — универсальный солдат, который всё умеет: и ручками, и автотесты, и DevOps по желанию. А по факту — либо страдает ручное тестирование, либо автоматизация, либо сразу оба направления. Сроки при этом никто не отменял. И всё это делается не потому, что «модно» или «так эффективно», а потому что проще платить одному специалисту 100 рублей, чем двум — по 200. Да и искать двух — долго. А если принюхаться к этой красивой обёртке — начинает пахнуть, мягко говоря, не очень.
Что касается QA-лидства: берёшь ответственность, коммуникации, развитие команды, планинги, контроль задач, плюс свои обычные таски. Через годик-другой уже понадобится помощь специалиста. И именно психотерапевта, потому что с психологом уже будет просто не о чем говорить. От постоянного переключения контекста можно по-настоящему тронуться головой.
Собственно, именно об этом и хотел рассказать в статье. Понимаю, что это глобально ничего не изменит. Но если хотя бы один человек это прочитает, узнает себя и ему это поможет — значит, не зря писал.
Согласен, такое реально часто встречается. И помимо people management'а (1:1, performance review, увольнения и всё прочее), ещё и обычные задачи никто не отменял — будь то фичи, баги или поддержка. Короче, ты и менеджер, и тимлид, и разработчик в одном лице. Один за всех, и всё на тебя.
Давно не видел такого отвратительного оформления, автор, забудьте про существование жирного шрифта, хочется глаза выколоть
Спасибо за обратную связь, пусть и в такой эмоциональной форме. Вы можете не любить жирный шрифт — это нормально. Только странно, что из всего технического содержания вы увидели только шрифт, а не суть статьи.
Если у вас есть собственное видение хорошего оформления — было бы интересно взглянуть на вашу статью. Пока её нет, выглядит так, будто вы просто пришли поскроллить комменты и бросить негатив.
Благодарю за столь эмоциональный и многословный комментарий. Видно, что мой скромный инструмент задел вас за живое, и это уже успех.
Ваш развернутый поток сознания заслуживает уважения — не каждый день можно увидеть столько страсти при обсуждении вопроса о покрытии UI. Особенно приятно, что вы нашли время написать целую стену текста, демонстрируя глубину боли, которую, судя по всему, моя работа вам причинила.
Теперь по сути:
Я рад, что вы открыли для себя различие между действиями и проверками. Поверьте, большинство людей в индустрии догадываются об этом даже без 5-страничных манифестов.
Касательно старых конференций, no-name решений и 19 минут на ознакомление: Удивительно, сколько презрения можно вложить в слова о событиях, о которых вы сами не так много знаете. К слову я лично был на этой конференции еще несколько лет назад и был в курсе про данное решение еще до того, как вы про него узнали. Не стесняйтесь, признание — первый шаг к принятию.
Ваше объяснение разницы между документацией, тест-кейсами и фактическим тестированием трогает своей наивностью. Вероятно, вы и вправду считаете, что TMS и красивые таблички спасают от багов в продакшене. Желаю удачи в этой вере.
Что касается "старых технологий" и морали пяти лет назад: Спасибо, что напомнили, что инновации для вас — это плохое слово. Видимо, в вашем мире рефакторинг под GO решает вопросы качества продукта лучше, чем инструменты контроля реального поведения тестов. Потрясающая логика.
По поводу отсутствия ассертов: Инструмент и не претендует на роль экстрасенса. Я не строю иллюзий, что могу угадать мысли тестировщика через отслеживание кликов. В отличие от некоторых, кто, судя по вашему тону, всерьез считает, что TMS отражает реальность тестирования.
В завершение хочу сказать: Если в будущем вам вновь захочется выплеснуть поток токсичности и обид за жизнь, не стесняйтесь — я рад видеть, что мой инструмент вызывает живые эмоции. А значит, он работает.
P.S.: Вместо скриншот-тестирования, как вы опасались, я, пожалуй, займусь еще одним полезным делом — выведу "coverage-психотерапию" в отдельную ветку разработки. Успех будет гарантирован — аудитория уже есть.
Благодарю за отзыв. Видимо, задел за живое.
Вы потратили столько времени на комментарий, что видно — тема действительно вас зацепила. И это хорошо: значит, я попал в настоящую боль индустрии. И видимо, потому что в реальности всё не так радужно.
Теперь к сути.
Да, идея трекать взаимодействия с UI не нова. Новый сам подход, делать это не через костыли и плагины в браузере. И нет, наличие старой статьи на Хабре не делает её реализацией ни массовой, ни удобной, ни применимой в реальных проектах. Потому что старая статья есть, но никто этим не пользуется.
Если бы всё было так идеально, как вы описываете с TMS и ручным линкованием тестов, в реальных компаниях не стоял бы вопрос:
«А что реально покрыто?»
«Где дырки в UI?»
«Почему баги всплывают на очевидных сценариях?»
TMS — это документация. Мой инструмент — это факт. Документация не показывает реальное поведение тестов на фронте. Никогда.
TMS показывает, что ЗАДУМАНО тестировать.
Мой инструмент показывает, что ФАКТИЧЕСКИ тестируется.
Хотя странно: если у вас всё настолько идеально через TMS, ручные тест-кейсы и процессы — зачем вы вообще читаете статьи про современные методы контроля покрытия?
Если по-честному — ваш подход морально устарел лет на пять.
Сегодня в реальных проектах автотесты пишутся сразу, без бумажной прослойки в TMS. Контроль покрытия — это не вера в чекбоксы в тест-менеджменте, а проверка реального поведения UI. Я понимаю, что хочется защищать старые процессы — в них вложено много сил. Но мир меняется. И если вам кажется, что инновации не нужны — это не значит, что они не работают.
Вы продолжаете говорить про процессы, как будто они волшебным образом решают всё. На практике процессы часто расходятся с реальностью, и я предлагаю инструмент, который это видно делает.
Мой инструмент показывает то, чего не видно в TMS:
Какие элементы реально затронуты тестами.
Какие остались без внимания.
Какие части UI "мертвым грузом" висят без тестового покрытия.
Если вы не видите в этом ценности — отлично. Это просто значит, что у вас другие задачи или другие масштабы. Но это не значит, что проблемы не существует.
И уж точно это не делает ваш комментарий чем-то большим, чем очередной спич в стиле "раньше было лучше". Мир меняется. Инструменты тоже.
P.S. Критиковать легче, чем создавать. Спасибо, что своим комментарием подчеркнули, что в отрасли по-прежнему нужен новый взгляд на проблему.
Спасибо за вопрос!
Если тесты мешают друг другу при запуске под одним пользователем — это уже первый красный флаг. Значит, между ними есть нежелательные зависимости, и они не изолированы. А это не баг, а фича плохого дизайна тестов/тестового фреймворка.
В идеале каждый тест должен работать в "песочнице": свои данные, своя сессия, никакой пересечки. Это достигается, как описано в статье, с помощью грамотно написанных фикстур, которые поднимают всё необходимое под капотом и изолируют окружение.
Но да, бывают случаи, когда тесты вынужденно гоняются под одним и тем же юзером — например, если у тебя пул аккаунтов ограничен. Тогда в ход идёт
pytest.mark.xdist_group. С ним можно сгруппировать тесты, которые не могут идти параллельно, и они будут исполняться в одном воркере, последовательно. Остальные при этом запустятся параллельно — и ты не жертвуешь всей скоростью.Но это — скорее "аварийный выход". Основной путь — делать независимые и изолированные тесты. Тогда и таких вопросов не возникнет
Спасибо за комментарий! А про параллельное выполнение тестов уже описывал в статье по API тестам, для UI тестов отличий никаких. Все решается установкой библиотеки
pytest-xdistи добавлением флага--numprocesses {number_of_workers}к команде запускаСпасибо большое за комментарий!
Матрица трассировки через CSV/XLSX — действительно очень распространённый и рабочий подход, особенно когда важна формальная связка требований и тестов. Вижу такое решение как классическую проверенную практику. Главный минус, как по мне, это необходимость ручной поддержки и человеческий фактор
В свою очередь, стараюсь минимизировать ручной труд, особенно в UI-части — хочется, чтобы покрытие можно было буквально “увидеть глазами”. И, конечно, чтобы всё обновлялось автоматически: один раз настроил — и дальше просто пользуешься.
Приятно видеть интерес к теме и разные подходы
Спасибо за комментарий!
Вы абсолютно правы в одном: любой отчёт, будь то Allure, отчет в CI, Excel или визуализация покрытия — нужно смотреть глазами и интерпретировать. Это не чип в голову, который сам всё объяснит — и, по-хорошему, он таким быть не должен.
Но тут как раз и появляется важный момент: возможность увидеть то, что иначе ты бы не заметил.
В случае с UI-покрытием это особенно важно — потому что элемент может "быть на странице", но никогда не покрываться ни одним тестом. И, к примеру, продакт может в любой момент спросить: "А у нас поиск вообще тестируется?" — и не получить чёткого ответа. А с таким отчётом ты просто открываешь страницу — и сразу видно, что покрыто, что нет.
Бизнесу это может быть нужно не в формате: "дайте мне отчёт", а в формате:
— а почему у нас на проде отвалился фильтр, вы же это тестируете?
— ммм... ну, не совсем...
И тогда такой отчёт — это буквально спасение.
Возможно, в статье стоило отдельно выделить раздел с примерами кейсов, чтобы это было понятнее. Добавлю
Спасибо за комментарий! Да, тут скорее про python было, думаю если бы был JS/TS, puppeteer однозначно можно было бы упомянуть, как например тот же cypress
Спасибо за комментарий! Да, подход правда хорош
Спасибо за вашу активность, давайте по порядку, спокойно, без эмоций:
Вы сами себе противоречите: сначала говорите "мы ничего не видим", потом — "всё равно ничего не покрыто". Так может как раз и видим?
Инструмент показывает то, что реально отрисовано, и в этом его сила. Он не гадает по облакам, он даёт фактическую картину.
Оставлю это без комментариев — не мой стиль мериться органами. Я тут про продукт и про факты, не про уличные перепалки с гопниками.
Вот тут вы сами ответили на свой же тезис: инструмент открыт, адаптируем, обсуждаем. Нравится идея — welcome, сделайте лучше. Вместо того, чтобы пытаться ткнуть пальцем, можно просто поучаствовать. Это не сарказм — это прямое приглашение.
Наоборот. Я с самого начала говорил: критику принимаю, если она идёт в связке с предложением или решением. Кричать "это всё фигня" — легко. Сделать PR — вот это польза.
Отчёт содержит графики, хронологию действий, снимки, динамику. Это не hello-world.json.
Да, он весит чуть больше, чем «проверка одного чекбокса», потому что он визуальный и подробный. Если он показывает что покрыто, как, когда и кем — 1MB за это более чем уместно.
Показываются. Потому что это — история. Как работали тесты тогда, что покрывали тогда. Это и есть point-in-time snapshot. Хочешь актуальное — запускай тесты заново и получишь актуальный отчёт. Всё честно.
Инструмент не претендует на всемирное господство. Он закрывает свою задачу — понятно, наглядно и прозрачно показать покрытие UI. Не вместо, а в дополнение.
Если вы это не видите — возможно, это просто не ваш кейс. Такое тоже бывает.
Но инструмент есть, он работает, и он реально помогает.
Спасибо за подробный фидбек, давайте по делу:
Про безопасность и X-Frame-Options
Да, в корпоративной среде есть ограничения, и они реальны. Но если подходить с таким критерием, то давайте вычеркнем и весь open source, который не покрывает 100% корпоративных кейсов. А это — почти всё.
На dev/stage можно отключить заголовки, можно поднять отчёт рядом, можно подгружать снимки и визуализировать отдельно. Это не проблема, это просто нюанс интеграции. У инструмента есть фокус — визуализировать покрытие UI, и он с этим справляется. Даже в корп-среде.
Про веру и максимализм
Я действительно верю в свой инструмент — потому что я его сделал. С нуля. Один. И он работает, этим пользуются, он приносит реальную пользу — это факт, а не эмоция.
Если у вас есть альтернатива — давайте посмотрим. Я открыт к конструктиву, но обсуждать "как должно быть" проще, чем сделать "как есть". Поэтому я привык слушать тех, кто тоже делает.
Про скрипт и безопасность
Любой скрипт можно форкнуть и держать у себя, как делают с Bootstrap, jQuery, любой CDN. Никто не заставляет подключать агент напрямую. Это инструмент, а не вирус. Исходники открыты — берите, собирайте, адаптируйте под себя.
P.S. И про минус — да нет, это не я XD Я в дискуссии за факты, не за кнопки.
Если коротко: инструмент не идеален, но он реален. Он уже решает задачи. А что-то, что "могло бы быть лучше", — ну так сделайте, покажите. Я первый скажу "круто".
"Когда ты сделал что-то своё, а тебе говорят, что оно 'неподходит под корп. среду'"
Я: «Зато оно вообще есть.»
Вы описали не проблему инструмента, а проблему отсутствия нормальных тестов. Инструмент ничего не скрывает — он показывает то, что реально трогают автотесты. Остальное не покрыто? Ну вот, теперь мы это видим. Добро пожаловать в реальность.
Да, звучит как будто вы прям расстроились, что не нашли критичных проблем. Но ничего, держу в курсе — инструмент будет развиваться, и багтрекер открыт. Можете оставить фидбек, если вдруг появится что-то конкретнее, чем "ой".
Ничего не мешает. Просто этот инструмент для визуального UI, а не для фантомных абстракций. Хотите интеграцию с виртуальными компонентами — флаг в руки, контрибьюшен открыт. Сделаете PR — я скажу спасибо и залью.
Именно. 1MB отчёта — это:
история действий,
интерактивный фрейм,
таймлайны,
подсветка элементов,
и вся аналитика.
Если вы считаете это "бесполезным", возможно, вам просто пока не приходилось разбираться с рефакторингом тестов и анализом покрытия.
Старые отчёты отражают то, как работали тесты тогда. Новый релиз — новые тесты. Захотел — пересобрал. Это не минус, это индикатор жизни проекта. Только мёртвый проект не меняется и не ломает покрытие.
Этот инструмент не решает все беды мира — зато он даёт реальный визуальный фидбек, без симуляций и фантазий.
Проблемы в UI-тестировании — это не "у нас слишком много вьюшек", а "у нас нет ни одного нормального инструмента, чтобы понять, что реально протестировано".
Вот теперь он есть.
Спасибо за мнение, но давайте по фактам
Сюрприз: именно поэтому инструмент и нужен. Чтобы увидеть, что реально покрыто, а что забыто. Он не заменяет здравый смысл или хороший тест-дизайн, он показывает фактическое покрытие. Это зеркало, а не костыль.
Инструмент работает, потому что архитектура простая и гибкая, а React идеально ложится под визуализацию и расширение через
postMessage. Можно не любить React, но это не мешает инструменту быть полезным и кастомизируемым.Если DOM не рендерится — значит, там и не с чем работать визуально. Это как жаловаться, что тепловизор не показывает невидимое. Этот инструмент не для всего подряд — он для UI, который реально отрисовывается.
Серьёзно? У нас в 2025-м отчёт весом 1MB — это уже много? Это как жаловаться на размер скриншота. Там графики, история, фрейм, интерактив — не просто текстовичок на коленке.
Ну… появятся непокрытые зоны. Это как раз плюс — вы сразу видите, где тесты устарели. Инструмент и не должен хранить вечную истину, он показывает текущее покрытие. Как бы если данные обновятся, то и тесты попадают. Чиним тесты, запускаем, видим новую картину покрытия.
Фишка в чём: этот инструмент — не панацея, не silver bullet. Это визуальный инструмент, который реально помогает понять, что происходит в UI.
Никто до меня это не делал на таком уровне — и если у вас есть что-то лучше, покажите. Я первый в очереди на то, чтобы посмотреть и сказать «вау».
Спасибо за развёрнутый комментарий
Про
iframeиX-Frame-Options— вы абсолютно правы: современные сайты, особенно корпоративные, действительно часто блокируют загрузку во фреймы, и это абсолютно оправданная мера против кликджекинга. Однако, инструментui-coverage-toolне предполагает работу с продакшеном напрямую, даже специально написан про это в статье. Он ориентирован на тестовые стенды, локальные версии и dev-сборки — там, где у разработчика/тестировщика есть контроль над конфигурацией.То есть, да,
X-Frame-Optionsможет мешать — и это нормально. Но в CI или при ручной проверке такой механизм работает идеально и дает визуальную обратную связь прямо на живом UI — что и было главной целью. Так что всё честно и реалистично в рамках применения.Насчёт скрипта
agent.global.js— это абсолютно резонный пойнт. Да, я бы тоже не стал подключать любой внешний скрипт в продакшн без ревью. Поэтому в статье прямо указано: использовать только на тестовом окружении.Плюс исходники полностью открыты: любой желающий может собрать агент вручную, посмотреть, как он работает, и адаптировать под свои нужды. Этот проект — не blackbox и не магия, а прозрачный инструмент, созданный разработчиком для разработчиков.
И если уже совсем паранойя, можно взять сделать форк/утащить себе локально и уж точно никто туда не вмешается
Про «идея не нова» — возможно, но я пока не встречал инструмента, который делает это именно так:
без необходимости менять код приложения,
без зависимости от конкретного фреймворка,
с визуализацией поверх живой страницы
и с возможностью отслеживать реальные действия из автотестов.
Если знаете аналог — с удовольствием посмотрю, будет интересно сравнить подходы. А пока — это первая публичная реализация такого рода с открытым исходным кодом
Спасибо ещё раз за интерес к проекту
Спасибо за комментарий! Рад, что материал оказался полезен
Добрый день! Давайте разбираться
Когда мы формируем Client мы можем передать в качестве аргумента base_url. При использовании Client для выполнения запросов, полный URL будет формировать автоматически "под капотом" httpx. Например:
Можно делать и через pydantic. По факту валидация через Pydantic уже выполняется, например тут
Pydantic действительно проверяет структуру данных и выдаст ошибку, если каких-то обязательных полей не будет. Однако у него есть один нюанс: он автоматически преобразует данные, если они пришли не в том формате. Например, если ожидается поле
number: int, а в JSON пришло"number": "100"(строка), Pydantic без ошибок преобразует строку в число.Да, начиная с Pydantic v2, в метод
model_validate_jsonможно передатьstrict=True, чтобы включить строгую проверку типов:Но у этого подхода есть недостатки:
Нужно каждый раз явно передавать
strict=True, что может быть забыто.Можно создать кастомную базовую модель, которая всегда включает
strict=True, но это усложняет проект. Даже если сделать кастомную модель, то у вас уже будет два метода: один из Pydantic для валидации модели из JSON, а второй ваш кастомный, и придется постоянно держать это в голове. А если придет новичок, то он точно про это не узнает.В итоге более надежное решение —
Использовать Pydantic для работы с данными (преобразование JSON → объект Python).
Использовать jsonschema для строгой проверки схемы.
Кроме того, вынесение проверки JSON-схемы в отдельную функцию позволяет:
Легко добавлять логирование и шаги Allure.
Гарантировать, что валидация всегда выполняется правильно.
Добавление Allure шагов и логирования на уровень методов pydantic, как будто идиоматически неверное решение
Как говорится если что-то плавает, как утка, выглядит как утка, крякает, как утка, то это утка)
Это все пустое, как по мне, в этом больше лицемерия, чем вайбов и софт скиллов. Скорее умение улыбаться, когда кого-то или даже тебя поливают грязью, но! Называют это критикой.
При этом если тебе не нравится эта критика или ее дает человек не компетентный, то скажут, что ты токсик и не умеешь воспринимать критику. Критика это хорошо, но только если меня будет критиковать любой бродяга с улицы, то пожалуй это будет не лучшая критика. Также и тут
Создание иллюзии дружелюбности в команде/компании, когда коллеги в чатах чуть ли не горло готовы друг другу перегрызть
Софт скиллы это скорее про умение договориться с кем угодно, о чем угодно, а не про полировку пятой точки начальству
Короче грустные вайбы, одно радует - так не во всех компаниях/командах
Всё так. Это заворачивается в красивую обёртку, подаётся под соусом «у нас модный процесс», где каждый QA — универсальный солдат, который всё умеет: и ручками, и автотесты, и DevOps по желанию. А по факту — либо страдает ручное тестирование, либо автоматизация, либо сразу оба направления. Сроки при этом никто не отменял. И всё это делается не потому, что «модно» или «так эффективно», а потому что проще платить одному специалисту 100 рублей, чем двум — по 200. Да и искать двух — долго. А если принюхаться к этой красивой обёртке — начинает пахнуть, мягко говоря, не очень.
Что касается QA-лидства: берёшь ответственность, коммуникации, развитие команды, планинги, контроль задач, плюс свои обычные таски. Через годик-другой уже понадобится помощь специалиста. И именно психотерапевта, потому что с психологом уже будет просто не о чем говорить. От постоянного переключения контекста можно по-настоящему тронуться головой.
Собственно, именно об этом и хотел рассказать в статье. Понимаю, что это глобально ничего не изменит. Но если хотя бы один человек это прочитает, узнает себя и ему это поможет — значит, не зря писал.
Согласен, такое реально часто встречается. И помимо people management'а (1:1, performance review, увольнения и всё прочее), ещё и обычные задачи никто не отменял — будь то фичи, баги или поддержка. Короче, ты и менеджер, и тимлид, и разработчик в одном лице. Один за всех, и всё на тебя.
Спасибо за обратную связь, пусть и в такой эмоциональной форме. Вы можете не любить жирный шрифт — это нормально. Только странно, что из всего технического содержания вы увидели только шрифт, а не суть статьи.
Если у вас есть собственное видение хорошего оформления — было бы интересно взглянуть на вашу статью. Пока её нет, выглядит так, будто вы просто пришли поскроллить комменты и бросить негатив.
Есть другая крайность, когда все друг другу улыбаются, улыбкой Гарольда, а за спиной измазывают отборной порцией нечистот