Комментарии 24
Вы, безусловно, талантливый и креативный человек, но...
1. "Этот сайт открывается внутри iframe прямо в отчёте." - Вы, видимо, не в курсе про атаки кликджекинга и методы защиты? нормальный сайт во фрейм не загрузить, этому препятствует это - https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options
Технически можно решить, донастроить, многие заголовки выставляются на nginx, а не в приложении, но внутреннюю безопасность никто не отменял. Ни одна крупная компания не пойдет на это.
2. Добавлять себе на сайт <script src="https://nikita-filonov.github.io/ui-coverage-report/agent.global.js"></script> без глубокого исследования скрипта - плохая практика. Плюс можно "забыть" убрать для продакшена и т.п., в общем, риски.Сама идея интересная, но не нова. Продолжайте, ищите вариант как можно меньше интегрировать тулзу с целью. С интересом смотрел на вашу другую вещь - покрытие api
Спасибо за развёрнутый комментарий
Про
iframeиX-Frame-Options— вы абсолютно правы: современные сайты, особенно корпоративные, действительно часто блокируют загрузку во фреймы, и это абсолютно оправданная мера против кликджекинга. Однако, инструментui-coverage-toolне предполагает работу с продакшеном напрямую, даже специально написан про это в статье. Он ориентирован на тестовые стенды, локальные версии и dev-сборки — там, где у разработчика/тестировщика есть контроль над конфигурацией.
То есть, да,X-Frame-Optionsможет мешать — и это нормально. Но в CI или при ручной проверке такой механизм работает идеально и дает визуальную обратную связь прямо на живом UI — что и было главной целью. Так что всё честно и реалистично в рамках применения.Насчёт скрипта
agent.global.js— это абсолютно резонный пойнт. Да, я бы тоже не стал подключать любой внешний скрипт в продакшн без ревью. Поэтому в статье прямо указано: использовать только на тестовом окружении.
Плюс исходники полностью открыты: любой желающий может собрать агент вручную, посмотреть, как он работает, и адаптировать под свои нужды. Этот проект — не blackbox и не магия, а прозрачный инструмент, созданный разработчиком для разработчиков.
И если уже совсем паранойя, можно взять сделать форк/утащить себе локально и уж точно никто туда не вмешаетсяПро «идея не нова» — возможно, но я пока не встречал инструмента, который делает это именно так:
без необходимости менять код приложения,
без зависимости от конкретного фреймворка,
с визуализацией поверх живой страницы
и с возможностью отслеживать реальные действия из автотестов.
Если знаете аналог — с удовольствием посмотрю, будет интересно сравнить подходы. А пока — это первая публичная реализация такого рода с открытым исходным кодом
Спасибо ещё раз за интерес к проекту
Минус-то за что? За обсуждение? Ну спасибо, конструктивно.
Тестовые стенды внезапно тоже должны покрываться безопасностью, в корпоративной среде приложения и test/dev стенды - монстры, локально их не поднимешь, и на них ИБ тоже будет требовать те же X-Frame-Options. Я вам пытаюсь показать, что этот инструмент имеет сильные ограничения в корп. среде. В мелких проектах - наверно да, можно попробовать применить.
Лично к Вам - вижу вашу безапелляционность к возражениям и слепую веру в свой идеальный продукт-детище. Юношеский максимализм - хорошо, но давайте больше конструктива и прислушиваться к советам и мнению других людей, Вы же пришли на Хабр не прокричать, какой вы гениальный и инновационный, а собрать обратную связь, правда же? Надеюсь, мы оба понимаем, что позитивная критика - это хорошо
Спасибо за подробный фидбек, давайте по делу:
Про безопасность и X-Frame-Options
Да, в корпоративной среде есть ограничения, и они реальны. Но если подходить с таким критерием, то давайте вычеркнем и весь open source, который не покрывает 100% корпоративных кейсов. А это — почти всё.
На dev/stage можно отключить заголовки, можно поднять отчёт рядом, можно подгружать снимки и визуализировать отдельно. Это не проблема, это просто нюанс интеграции. У инструмента есть фокус — визуализировать покрытие UI, и он с этим справляется. Даже в корп-среде.
Про веру и максимализм
Я действительно верю в свой инструмент — потому что я его сделал. С нуля. Один. И он работает, этим пользуются, он приносит реальную пользу — это факт, а не эмоция.
Если у вас есть альтернатива — давайте посмотрим. Я открыт к конструктиву, но обсуждать "как должно быть" проще, чем сделать "как есть". Поэтому я привык слушать тех, кто тоже делает.
Про скрипт и безопасность
Любой скрипт можно форкнуть и держать у себя, как делают с Bootstrap, jQuery, любой CDN. Никто не заставляет подключать агент напрямую. Это инструмент, а не вирус. Исходники открыты — берите, собирайте, адаптируйте под себя.
P.S. И про минус — да нет, это не я XD Я в дискуссии за факты, не за кнопки.
Если коротко: инструмент не идеален, но он реален. Он уже решает задачи. А что-то, что "могло бы быть лучше", — ну так сделайте, покажите. Я первый скажу "круто".
"Когда ты сделал что-то своё, а тебе говорят, что оно 'неподходит под корп. среду'"
Я: «Зато оно вообще есть.»
Интересно, на поиграться, но реальной пользы вижу мало - в реальном приложении много вьюшек, которые с ходу не видны. Так что всё, что ты увидишь - несколько очевидных тестовых сценариев и всё.
лёгкая, но гибкая архитектура на React + PostMessage, которая масштабируется и кастомизируется под любые нужды. Благодаря React и открытой архитектуре, можно написать всё что угодно и куда угодно.
Примечательно, что именно в Реакте появилось разделение на "умные" и "глупые" компоненты. Не от хорошей жизни. В нём очень сложно сделать что-то на настоящему гибкое. Так что если вы что-то такое и сделали, то не "благодаря", а "вопреки".
Лимитации? Пока не обнаружены. Инструмент активно тестируется в боевых условиях, и пока ни одной критичной лимитации замечено не было.
У нас, например, ui-тесты не рендерят по чём зря DOM дерево. Вот, например, страница, где тестируется приложение (отчёт выводится в консоль). Как вы подсветите, какие компоненты протестированы и насколько качественно?
Лёгкий как перышко. Отчёт весит всего ~1MB — с историей, фреймом, графиками и всей аналитикой.
Как-то многовато. У вас там дамп Войны и Мира зашит что ли?
Работа с реальным приложением, а не копией. Вы работаете с живым приложением во фрейме. Можно изменить состояние, перезагрузить и сразу увидеть изменения. Это не реплей, это реальность.
Во что превратится отчёт, когда приложение или данные обновятся?
Спасибо за мнение, но давайте по фактам
"В реальном приложении много вьюшек, которые с ходу не видны"
Сюрприз: именно поэтому инструмент и нужен. Чтобы увидеть, что реально покрыто, а что забыто. Он не заменяет здравый смысл или хороший тест-дизайн, он показывает фактическое покрытие. Это зеркало, а не костыль.
"React — не от хорошей жизни"
Инструмент работает, потому что архитектура простая и гибкая, а React идеально ложится под визуализацию и расширение через postMessage. Можно не любить React, но это не мешает инструменту быть полезным и кастомизируемым.
"DOM не рендерится, ничего не подсветите"
Если DOM не рендерится — значит, там и не с чем работать визуально. Это как жаловаться, что тепловизор не показывает невидимое. Этот инструмент не для всего подряд — он для UI, который реально отрисовывается.
"1MB — многовато"
Серьёзно? У нас в 2025-м отчёт весом 1MB — это уже много? Это как жаловаться на размер скриншота. Там графики, история, фрейм, интерактив — не просто текстовичок на коленке.
"Что будет, когда данные обновятся?"
Ну… появятся непокрытые зоны. Это как раз плюс — вы сразу видите, где тесты устарели. Инструмент и не должен хранить вечную истину, он показывает текущее покрытие. Как бы если данные обновятся, то и тесты попадают. Чиним тесты, запускаем, видим новую картину покрытия.
Фишка в чём: этот инструмент — не панацея, не silver bullet. Это визуальный инструмент, который реально помогает понять, что происходит в UI.
Никто до меня это не делал на таком уровне — и если у вас есть что-то лучше, покажите. Я первый в очереди на то, чтобы посмотреть и сказать «вау».
Сюрприз: именно поэтому инструмент и нужен. Чтобы увидеть, что реально покрыто, а что забыто.
На одном экране видно хорошо если 1% от того, что реально надо покрыть тестами, а до остальных ещё добраться надо.
Этот инструмент не для всего подряд — он для UI, который реально отрисовывается. этот инструмент — не панацея, не silver bullet.
Ой, лимитации.
Можно не любить React, но это не мешает инструменту быть полезным и кастомизируемым.
Ну раз она такая гибкая, то что мешает поддержать фреймворки, которые не рендерят весь DOM в тестах?
Серьёзно? У нас в 2025-м отчёт весом 1MB — это уже много?
Много/мало определяется не годом, а соотношением полезной информации к бесполезной.
Ну… появятся непокрытые зоны. Это как раз плюс — вы сразу видите, где тесты устарели.
То есть старые отчёты превращаются в тыкву, понятно.
"На одном экране видно хорошо если 1% от того, что реально надо покрыть тестами, а до остальных ещё добраться надо."
Вы описали не проблему инструмента, а проблему отсутствия нормальных тестов. Инструмент ничего не скрывает — он показывает то, что реально трогают автотесты. Остальное не покрыто? Ну вот, теперь мы это видим. Добро пожаловать в реальность.
"Ой, лимитации."
Да, звучит как будто вы прям расстроились, что не нашли критичных проблем. Но ничего, держу в курсе — инструмент будет развиваться, и багтрекер открыт. Можете оставить фидбек, если вдруг появится что-то конкретнее, чем "ой".
"Что мешает поддержать фреймворки, которые не рендерят весь DOM в тестах?"
Ничего не мешает. Просто этот инструмент для визуального UI, а не для фантомных абстракций. Хотите интеграцию с виртуальными компонентами — флаг в руки, контрибьюшен открыт. Сделаете PR — я скажу спасибо и залью.
"Много/мало определяется не годом, а соотношением полезной информации к бесполезной."
Именно. 1MB отчёта — это:
история действий,
интерактивный фрейм,
таймлайны,
подсветка элементов,
и вся аналитика.
Если вы считаете это "бесполезным", возможно, вам просто пока не приходилось разбираться с рефакторингом тестов и анализом покрытия.
"Старые отчёты превращаются в тыкву"
Старые отчёты отражают то, как работали тесты тогда. Новый релиз — новые тесты. Захотел — пересобрал. Это не минус, это индикатор жизни проекта. Только мёртвый проект не меняется и не ломает покрытие.
Этот инструмент не решает все беды мира — зато он даёт реальный визуальный фидбек, без симуляций и фантазий.
Проблемы в UI-тестировании — это не "у нас слишком много вьюшек", а "у нас нет ни одного нормального инструмента, чтобы понять, что реально протестировано".
Вот теперь он есть.
Остальное не покрыто? Ну вот, теперь мы это видим. Добро пожаловать в реальность.
Не видим, ибо смотрим через замочную скважину, показывающую 1% приложения.
Да, звучит как будто вы прям расстроились, что не нашли критичных проблем.
Звучит так, что я уличил вас во лжи, а вам не хватает размера яиц это признать.
Хотите интеграцию с виртуальными компонентами — флаг в руки, контрибьюшен открыт. Сделаете PR — я скажу спасибо и залью.
Если вы ждёте от сообщества помощи, то выбрали неправильную стратегию общения с ним. Попробуйте не строить из себя упоротого маркетолога.
Если вы считаете это "бесполезным", возможно, вам просто пока не приходилось разбираться с рефакторингом тестов и анализом покрытия.
Я считаю всё это весит 100кб в прыжке. Думаю у вас там много мусора, который стоит удалить, а не кичиться тем, что у вас "всего" мегабайт.
Старые отчёты отражают то, как работали тесты тогда. Новый релиз — новые тесты.
Так не отражают же. У вас старые отчёты показываются с новым приложением. И с каждым апдейтом показания в этом отчёте разные.
Спасибо за вашу активность, давайте по порядку, спокойно, без эмоций:
Не видим, смотрим через замочную скважину
Вы сами себе противоречите: сначала говорите "мы ничего не видим", потом — "всё равно ничего не покрыто". Так может как раз и видим?
Инструмент показывает то, что реально отрисовано, и в этом его сила. Он не гадает по облакам, он даёт фактическую картину.
Уличил во лжи / яйца / признание
Оставлю это без комментариев — не мой стиль мериться органами. Я тут про продукт и про факты, не про уличные перепалки с гопниками.
Контрибьюшен открыт
Вот тут вы сами ответили на свой же тезис: инструмент открыт, адаптируем, обсуждаем. Нравится идея — welcome, сделайте лучше. Вместо того, чтобы пытаться ткнуть пальцем, можно просто поучаствовать. Это не сарказм — это прямое приглашение.
Выбрали неправильную стратегию общения
Наоборот. Я с самого начала говорил: критику принимаю, если она идёт в связке с предложением или решением. Кричать "это всё фигня" — легко. Сделать PR — вот это польза.
100кб в прыжке / мусор
Отчёт содержит графики, хронологию действий, снимки, динамику. Это не hello-world.json.
Да, он весит чуть больше, чем «проверка одного чекбокса», потому что он визуальный и подробный. Если он показывает что покрыто, как, когда и кем — 1MB за это более чем уместно.
Старые отчёты показываются с новым приложением
Показываются. Потому что это — история. Как работали тесты тогда, что покрывали тогда. Это и есть point-in-time snapshot. Хочешь актуальное — запускай тесты заново и получишь актуальный отчёт. Всё честно.
Инструмент не претендует на всемирное господство. Он закрывает свою задачу — понятно, наглядно и прозрачно показать покрытие UI. Не вместо, а в дополнение.
Если вы это не видите — возможно, это просто не ваш кейс. Такое тоже бывает.
Но инструмент есть, он работает, и он реально помогает.
P.S. И да, если вы увидели всего 1% — возможно, пора протереть глаза и посмотреть шире.
Если вы ждёте от сообщества помощи, то выбрали неправильную стратегию общения с ним. Попробуйте не строить из себя упоротого маркетолога.
ой, а кто это говорит?
может тот человек, которому миллион раз говорили что есть общепринятые нормы написания кода, а он им не следует? тот, кто на любую критику чуть ли не посылает человека в пешее эротическое? или же комментатор, который приходит в любой пост про фронтенд тематику и говорит какой крутой его мол (по поводу и без. ну, скорее всего не в тему)?
хотя не, скорее всего, это говорит человек, который строит стратегию пиара своего продукта на принципе "вы все дибилы и не лечитесь, а один тут шарю как надо"
ну камон, чел, сначала меня это забавляло, но в последнее время реал бесить начало. нафига докапываться до людей постоянно?
ой, а кто это говорит?
Очевидно, человек не понаслышке знающий, о чём говорит.
может тот человек, которому миллион раз говорили что есть общепринятые нормы написания кода, а он им не следует?
Тот человек, который провёл технический анализ вопроса, например.
тот, кто на любую критику чуть ли не посылает человека в пешее эротическое?
Приведите ссылку, где я кого-то "чуть ли не посылаю" - посмотрим, насколько обоснована была эта "любая критика".
или же комментатор, который приходит в любой пост про фронтенд тематику и говорит какой крутой его мол (по поводу и без. ну, скорее всего не в тему)?
Опять же, покажите хоть одно моё сообщение из 10К на Хабре, написанное не в тему.
это говорит человек, который строит стратегию пиара своего продукта
У вас маркетинг головного мозга уже, раз везде мерещатся продукты, которые вам типа продают.
вы все дибилы и не лечитесь, а один тут шарю как надо
И я подкрепляю свои слова пруфами. Но, к сожалению, дебилизм пруфами не лечится.
сначала меня это забавляло, но в последнее время реал бесить начало
Попробуйте обратиться ко психотерапевту с этим вопросом, не запускайте.
нафига докапываться до людей постоянно?
Ок, отвечу на понятном вам языке: слыш, пацанчик, ты чё к бате докопался? Череп сильно жмёт?
Если вы ждёте от сообщества помощи, то выбрали неправильную стратегию общения с ним.
Иронично
Ну ок, такой вопрос:
Безусловно, проект талантливый, но по как мне, так я все отчеты генерю в первую очередь для бизнеса, а во вторую для себя.
Что говорит бизнес, когда смотрит на получившуюся отчетность? Те, для кого количество кликов, количество элементов - штуки абстрактные скорее всего. Удобно конечно, что можно "подсветить", но теперь надо ходить считать сколько подсвеченно, а сколько нет? Или я прочитал невнимательно и что то упустил?
Другими словами: бизнес пользует вашу отчетность?
Спасибо за комментарий!
Вы абсолютно правы в одном: любой отчёт, будь то Allure, отчет в CI, Excel или визуализация покрытия — нужно смотреть глазами и интерпретировать. Это не чип в голову, который сам всё объяснит — и, по-хорошему, он таким быть не должен.
Но тут как раз и появляется важный момент: возможность увидеть то, что иначе ты бы не заметил.
В случае с UI-покрытием это особенно важно — потому что элемент может "быть на странице", но никогда не покрываться ни одним тестом. И, к примеру, продакт может в любой момент спросить: "А у нас поиск вообще тестируется?" — и не получить чёткого ответа. А с таким отчётом ты просто открываешь страницу — и сразу видно, что покрыто, что нет.
Бизнесу это может быть нужно не в формате: "дайте мне отчёт", а в формате:
— а почему у нас на проде отвалился фильтр, вы же это тестируете?
— ммм... ну, не совсем...
И тогда такой отчёт — это буквально спасение.
Возможно, в статье стоило отдельно выделить раздел с примерами кейсов, чтобы это было понятнее. Добавлю
Очень интересное решение! До сих пор я лично пользуюсь матрицей трассировки в xlsx-формате, которая генерируется автоматически на основе двух csv-таблиц. Csv-шки заполняются уже вручную. Первая содержит описание областей покрытия (чаще всего постраничное) сопоставляемое с требованиями. Вторя - это словарь покрытия, где каждое требование расписано в виде "синонимов", буквально отражающих названия БДД-сценариев из тестов.
Спасибо большое за комментарий!
До сих пор я лично пользуюсь матрицей трассировки в xlsx-формате, которая генерируется автоматически на основе двух csv-таблиц. Csv-шки заполняются уже вручную.
Матрица трассировки через CSV/XLSX — действительно очень распространённый и рабочий подход, особенно когда важна формальная связка требований и тестов. Вижу такое решение как классическую проверенную практику. Главный минус, как по мне, это необходимость ручной поддержки и человеческий фактор
В свою очередь, стараюсь минимизировать ручной труд, особенно в UI-части — хочется, чтобы покрытие можно было буквально “увидеть глазами”. И, конечно, чтобы всё обновлялось автоматически: один раз настроил — и дальше просто пользуешься.
Приятно видеть интерес к теме и разные подходы
Это мой инновационный инструмент
Слова громкие, но этой идее уже лет пять: https://habr.com/ru/companies/jugru/articles/491844/. Хотя если так подумать, то любой ваш инструмент будет для вас инновационным, даже если его уже сделали другие люди 20 лет назад.
Сейчас нет ни одного нормального способа понять, что реально покрыто UI-тестами. Но... Теперь есть.
Да всегда это было — TMS. В реальном проекте локаторы с графиками интересны тем, кто их до этого не видел. Через день это станет белым шумом. Ваш "инструмент" добавляет только дополнительный код в проект (как минимум это добавляет накладные расходы и непонятные перспективы). Старая концепция работы через отчет намного лучше и продуманнее, чем ваша идея. Да даже вы сами ссылаетесь на Cypress UI Coverage — там есть связь с тестами.
Ну давайте честно, как сейчас обычно проверяют покрытие UI-тестов?
Никак
Ну это вранье (= Так себе начинать с этого статью на техническом ресурсе.
Можно строить матрицы покрытий, таблицы, рисовать дашборды в TMS. Выглядит красиво. Но по факту — всё устаревает быстрее, чем успевает появиться. И если вы когда-то вручную пытались оценить покрытие UI — вы знаете, как быстро это становится бессмысленным.
Странный аргумент. Но, что самое смешное, он более чем применим к тому, что вы "придумали". Видимо, вы не в курсе, раз пишите такое, но нормальный процесс автоматизации тесткейсов строится так:
Берется ручной тесткейс (который адаптирован для автоматизации, проверен и т.д.)
Автоматизируется (ему проставляется id из TMS для линковки и не только)
Отмечается как автоматизированный в TMS
И на дашборде теперь видно, сколько автоматизировано, а сколько нет. Устареть эта информация может только если вообще перестать вести TMS. Но это вопросы к процессам и там уже совсем другие проблемы в таком случае вырисовываются. Каждый запуск автотестов будет помечать данный тесткейс результатом из прогона. В некоторых TMS даже в режиме реального времени. Просто ноль устаревания, зато максимум смысла.
А вот "Выглядит красиво" — а это скорее про ваши столбики в "Total number of elements" и подобном, пользы от которых как от числа строк кода — вроде бы цифра есть, но применить ее некуда.
Пишем мы, значит, UI-тесты. Запускаем. Они что-то проверяют, что-то кликают, иногда даже баги находят. Но вот вопрос — что именно они проверяют? И насколько качественно?
Открывается отчет, в котором всё должно быть. Если этого нет, то надо налаживать процессы. Уж извините, но это шизофренией отдает, когда вы не доверяете написанным тестам и вместо этого лезете в какой-то отчет, в котором вообще нет ничего про тесткейсы.
А кнопку в настройках юзера, которая в модалке?
А то, что при незаполненной форме кнопка неактивна?
А если текст обрезался в navbar-ре — кто это заметит?
И, как ни странно, снова информация в TMS, где будет линковка между тесткейсом и автотестом. Если у вас не так, то соболезную, но своим инструментом вы эту проблему не решаете от слова "никак". Более того, если у вас 20 взаимодействий с активной кнопкой при заполненном поле, и 2 при незаполненном, то как вы поймете, что проверка на неактивность при незаполненности должно быть 3? Ну вот просто три кейса должно быть автоматизировано на неактивность. У вас инструмент показывает, что 2. Но вы же не смотрите в TMS, а значит инструмент просто бесполезен для вашего же примера.
Написал тесты. Посмотрел в терминал. Всё зелёное. Ну вроде молодец? А потом открываешь отчёт — и видишь, что по факту проверяется три кнопки и один h1.
Если эти три кнопки и один h1 покрывают бизнес-логику, то молодец. У вас странные примеры. Можно придумать аналогичный, но в обратную сторону — "Покрыты 50 кнопок и все поля ввода! Ну, вроде молодец! А потом открываешь тесткейсы, а там надо было проверять бизнес-логику".
Ревью автотестов без экстрасенсорики
При этом для понимания по вашему отчету, зачем нужен был клик, нужна экстрасенсорика более сильных магов с ТНТ, ведь в отчете кода не будет.
“А какие части UI у нас вообще не покрыты тестами?” — классика. С этим инструментом можно буквально ткнуть в отчёт и сказать:
Не надо говорить, надо смотреть в TMS, где должны быть отмечены уже автоматизированные тесткейсы.
В реальном мире если у вас 20 тестов, которые начинаются с клика одной кнопки, вы получите просто 20 отметок о клике, которые не скажут, что покрыто, а что нет. Видимо, надо уточнить, что покрытие это не увидеть, что по кнопке был сделан клик и проверено состояние. Без контекста в этом нет смысла. Вы почему-то приводите ровно то, что выгодно вам. Совершенно не учитывая, что не всё надо покрывать, что такое покрытие вообще ничего не даст. Что надо отталкиваться не от него, а от тесткейсов и смотреть в них в первую очередь. И что отчет без них не имеет смысла, т.к. визуально трассировка шагов у вас не прослеживается. Также не учитывается, что есть подготовка тестовых данных (или изменение их во время теста) через api, что не будет отображено на UI, то есть элемент может быть вообще не отмечен. Также если у вас есть какая-то отметка, что проверена видимость кнопки, то это не говорит о том, что пропущен кейс на задизейбленность и т.д. То есть без тесткейсов это бесполезно. Но если есть тесткейсы и там есть все эти шаги и проверки, то зачем смотреть визуально? Вы предлагаете от отсутствия проверки на элементе подниматься наверх и смотреть на связанные тесткейсы. Когда должно быть наоборот — из тесткейсов строится покрытие. И если оно было плохое там, то это не сторонний инструмент должен показывать, а ревью тесткейсов (для этого есть разбивка по user story). Но, допустим, что какую-то кнопку не надо вообще покрывать. Проджект так сказал (функционал меняется, или не приоритет). Но вы каждый раз в отчете видите, что она не покрыта и перестаёте понимать свои же придуманные coverage-критерии.
Ты просто открываешь отчёт, показываешь страницу — и видно:
есть ли этот селектор;
тестировался ли он;
И продакт спрашивает — "а вот эта user story покрыта?", и ты такой "Ну, эээ... вроде да, по моему отчету этого нет, только селектор". И вот ключевая проблема (помимо того, что не будут смотреть отчет, это на уровне скриншотов и видео всех запусков) — отметки о кликах и проверках бесполезны без привязки к тестам. И в статье, на которую я ссылаюсь в самом начале, все это было сделано. Да, пять лет назад. Так что увы, сегодня без инноваций.
Вот этим статья больше похожа на маркетинговый bullshit:
Инновационный инструмент для визуализации UI-покрытия, который на момент написания этой статьи ... Это реально киллер-фича ... Вот он — контроль эволюции качества ... Это такой уровень прозрачности, которого раньше не было ни в одном UI-репорте ... это настоящий прорыв в области UI-автоматизации ... меняет подход к тестированию.
и прочие восторженные фразы для продажи, но не для реального дела.
В целом почти все аргументы статьи строятся на том, что процессы автоматизации, да и тестирования, отсутствуют напрочь, но их каким-то чудом должен закрыть отчет. Хотя по приведенным примерам решаются искусственно выдуманные проблемы.
С другой стороны если вы изучите старое решение, посмотрите, как оно реализовано, добавите в своё (уберете из своего отчеты, они вообще не нужны), то в этом уже появится некоторый смысл.
Благодарю за отзыв. Видимо, задел за живое.
Вы потратили столько времени на комментарий, что видно — тема действительно вас зацепила. И это хорошо: значит, я попал в настоящую боль индустрии. И видимо, потому что в реальности всё не так радужно.
Теперь к сути.
Да, идея трекать взаимодействия с UI не нова. Новый сам подход, делать это не через костыли и плагины в браузере. И нет, наличие старой статьи на Хабре не делает её реализацией ни массовой, ни удобной, ни применимой в реальных проектах. Потому что старая статья есть, но никто этим не пользуется.
Если бы всё было так идеально, как вы описываете с TMS и ручным линкованием тестов, в реальных компаниях не стоял бы вопрос:
«А что реально покрыто?»
«Где дырки в UI?»
«Почему баги всплывают на очевидных сценариях?»
TMS — это документация. Мой инструмент — это факт. Документация не показывает реальное поведение тестов на фронте. Никогда.
TMS показывает, что ЗАДУМАНО тестировать.
Мой инструмент показывает, что ФАКТИЧЕСКИ тестируется.
Хотя странно: если у вас всё настолько идеально через TMS, ручные тест-кейсы и процессы — зачем вы вообще читаете статьи про современные методы контроля покрытия?
Если по-честному — ваш подход морально устарел лет на пять.
Сегодня в реальных проектах автотесты пишутся сразу, без бумажной прослойки в TMS. Контроль покрытия — это не вера в чекбоксы в тест-менеджменте, а проверка реального поведения UI. Я понимаю, что хочется защищать старые процессы — в них вложено много сил. Но мир меняется. И если вам кажется, что инновации не нужны — это не значит, что они не работают.
Вы продолжаете говорить про процессы, как будто они волшебным образом решают всё. На практике процессы часто расходятся с реальностью, и я предлагаю инструмент, который это видно делает.
Мой инструмент показывает то, чего не видно в TMS:
Какие элементы реально затронуты тестами.
Какие остались без внимания.
Какие части UI "мертвым грузом" висят без тестового покрытия.
Если вы не видите в этом ценности — отлично. Это просто значит, что у вас другие задачи или другие масштабы. Но это не значит, что проблемы не существует.
И уж точно это не делает ваш комментарий чем-то большим, чем очередной спич в стиле "раньше было лучше". Мир меняется. Инструменты тоже.
P.S. Критиковать легче, чем создавать. Спасибо, что своим комментарием подчеркнули, что в отрасли по-прежнему нужен новый взгляд на проблему.
Благодарю за отзыв. Видимо, задел за живое.
Вы потратили столько времени на комментарий, что видно — тема действительно вас зацепила. И это хорошо: значит, я попал в настоящую боль индустрии.
Благодарю за внимание к теме. Видимо, моя критика задела за живое, раз за 19 минут вы успели ознакомиться и с моим комментарием, и со статьей по ссылке, может даже ролик посмотрели, там всего лишь час, да еще и ответ написали! Впечатляет.
Новый сам подход, делать это не через костыли и плагины в браузере.
Подкладывание файлов, какая-то установка, менять код зачем-то — не костыли. Ноль двойных стандартов. При этом в вашем же примере есть импорт аллюра, который генерирует более чем достаточную информацию для подобной визуализации.
Потому что старая статья есть, но никто этим не пользуется.
Хорошо, что есть человек, способный говорить за всех, который, правда, не удосужился понять, почему идея не внедрились, но куда там, 19 минут, некогда думать. То решение было показано всего лишь на какой-то никому не известной конференции, рекламы которой нет ни в баннерах, ни в рассылках. Нонеймы, что с них взять, jugru какой-то, а кто их знает — всего лишь десяток лет что-то делают.
Хорошая попытка заменить старую статью якобы новым подходом, но нет. У вас странная позиция во всем ответе, что если что-то старое, то оно плохое. Это даже не столько глупо, сколько непрофессионально.
Если бы всё было так идеально, как вы описываете с TMS и ручным линкованием тестов
Если ваши тесткейсы не покрывают нужные сценарии, то циферки в айфрейме уж тем более не смогут показать ничего внятного. Вот вам такой вот факт, как раз это ваш инструмент. Идеальность здесь не при чем, это базовый элемент работы.
TMS — это документация.
TMS это Test Management System или же Система Управления Тестированием. Если вы путаете TMS с документацией, то пора бы освежить знания в области тестирования. То, что вы пишете, показывает очень плохой уровень понимания процессов.
Мой инструмент — это факт. Документация не показывает реальное поведение тестов на фронте. Никогда.
Вот этот уровень, например. Если у вас тесткейсы в TMS не содержат ожидаемого поведения, то вы на одном берегу, а тестирование на другом. И между вами океан под названием "Никогда". Документация не должна показывать реальное поведение. Она должна просто иметь описание ожидаемого и шаги.
TMS показывает, что ЗАДУМАНО тестировать.
Вы используете странные слова. Вот реально, подучите теорию тестирования что ли. В этом предложении неправильно просто всё. Я помогу — Тесткейс это набор последовательных действий с ожидаемым результатом. Тут нет ничего про "задумано", но есть алгоритм, который должен быть основан на документации по продукту. И да, если вы не можете организовать рабочий процесс, чтобы было покрытие по сторям/фичам/эпикам, то это повод задуматься о своей компетенции.
Мой инструмент показывает, что ФАКТИЧЕСКИ тестируется.
Это вы будете с такими фразами его продавать. Потому что ваш инструмент показывает только взаимодействия. Вот я открыл ваш пример, инпут Email. Как у вас по отчету понять, что проверяется введенная информация? А никак. У вас просто отчет "Fill: 8", "Value: 8". 8 раз заполнили и 8 раз что-то там с value сделали — но менеджер спросит, "какие кейсы покрывают поле email?" — что ответите? А ничего. Зато график красивый.
И в итоге вопрос «А что реально покрыто?» просто за бортом. Тонет в "Никогда" рядом с «Где дырки в UI?» и «Почему баги всплывают на очевидных сценариях?». Подсказка — проверки это assert. У вас их нет. У вас (чуть другой пример, но тоже для email) — Fill: 5, Value: 7, Visible: 2. Мы проверили видимость обязательного поля два раза? Заполнили 5 раз, но взяли значение 7 раз? По такому результату может быть что угодно и оно никак не соотносится с покрытием. У вас есть проверка заполнения поля? Тоже нет. Есть какое-то "Value: 8". Пустое? Заполненное? Какие цифры/буквы, сколько их? Самый простой джуновский вопрос на тестирование формы накинет кучу адекватных сценариев, но все они будут у вас в отчете как "Value: 8", которое просто значит, что тут что-то вводили 8 раз (вернее, что метод сработал столько раз). При этом это могло быть как в 1 тесте, так и в 8 — информации об этом тоже нет. И вы еще что-то писали про экстрасенсов. А метрики кликов и прочего можно подключать через яндекс. Да любой, кто видел вебвизор, думал о внедрении подобного в автотесты.
Хотя странно: если у вас всё настолько идеально через TMS, ручные тест-кейсы и процессы — зачем вы вообще читаете статьи про современные методы контроля покрытия?
Ваша статья не имеет никакого отношения ни к современному, ни к методу контроля, ни к покрытию. Не говоря уже о том, что у вас код на старых технологиях. Сейчас GO в моде. С другой стороны вот вы сделали инструмент, который должен был показывать покрытие, но он этого не делает. Получается, что мы оба не получили то, что хотели. Иронично, не правда ли.
Если по-честному — ваш подход морально устарел лет на пять.
Мои подход не старый — документация и процессы это признак зрелости команды. Зато вы поиграли в песочнице гитхаба. Каждому своё уровень занятий.
Сегодня в реальных проектах автотесты пишутся сразу, без бумажной прослойки в TMS.
И пишутся прослойкой между монитором и стулом.
Еще скажите, что без документации реальные проекты делаются. И потом сделайте круглые глаза, когда спросят «Почему баги всплывают на очевидных сценариях?». И внезапно после такого люди начинают бегать с горящей пятой точкой, искать доки по чатам и создавать нормальную вики, затем тесткейсы, затем автотесты или cases-as-code.
Контроль покрытия — это не вера в чекбоксы в тест-менеджменте, а проверка реального поведения UI.
Сами придумали аргумент про веру и сами его героически опровергли. Сильный подход.
Контроль покрытия здесь вообще не в кассу. Видимо, у вас нет базы по тестированию, чтобы адекватно формулировать мысли в данной области. Но галочки в TMS точно таким же образом бесполезны, что и ваши отметки с кликами. Только вот в TMS можно увидеть покрытие по сценариям, а у вас в отчете нет.
Я понимаю, что хочется защищать старые процессы — в них вложено много сил. Но мир меняется.
Моя любимая ложная дихотомия "старое плохое, новое хорошее".
Вы так пишете, как будто ваша "разработка" это что-то морально новое. Вообще нет. Не очень понял, при чем тут возраст процессов. Процессы либо есть, либо их нет. Возраст не влияет на их качество, а вот люди, которые их используют — да. Кардинально нового за последние 20 лет ничего не придумали. Хотите нового — попробуйте поесть ногами вместо рук, это будет свежо. Инноваций в статье нет. Я понимаю, что хочется защищать свою разработку — в нее вложено много сил. Но мир меняется. И если вам кажется, что вы что-то придумали — это не значит, что до вас это не было сделано (более качественно к тому же).
И если вам кажется, что инновации не нужны — это не значит, что они не работают.
Опять сами героически опровергли выдуманный собой же аргумент. Герой! Но принцесса в другом замке. При этом необходимость инноваций не гарантирует, что они будут работать. Вы бы хоть думали перед ответами, а то я за вас пояснения вношу.
Вы продолжаете говорить про процессы, как будто они волшебным образом решают всё. На практике процессы часто расходятся с реальностью,
Значит вы просто не видели нормальных. Очень жаль. И если вам кажется, что процессы не нужны — это не значит, что они не работают. Тут бы мне еще придумать аргумент про инновации, решающие что-то волшебным образом, а затем опровергнуть, но, пожалуй, откажусь.
и я предлагаю инструмент, который это видно делает. Мой инструмент показывает то, чего не видно в TMS
Не, это мы проходили — не делает вообще ничего реально полезного. Только лишний код, лишние файлы, лишние зависимости.
Напомню пример ваш же выше — поле email "Fill: 8", "Value: 8". Что тут покрыли? Сколько сценариев? Какие позитивные, а какие негативные? Без привязки к кейсам (которая реализована в статье и вроде как в сайпресе) вы собрали статистику, которая не дает объективной картины. Как статистика поля email покрывает кейс с выделением его красным при клике по кнопке входа, если там сложный реакт-компонент с десятком врапперов внутри, часть их которых в shadowroot? Подсказка — никак. И таких реальных кейсов из реального мира (это из того, про который вы говорите, ну тот, который меняется и всё такое). Ваше "покрытие" это фикция, не более. Оно не имеет отношения к покрытию реальному, потому что нет метрик по сценариям
Если вы не видите в этом ценности — отлично. Это просто значит
что в данном случае ее реально нет. Было бы неплохо сначала провести полноценный анализ, погуглить coverage по инструментам, тогда вы бы сделали иначе. Но анализ это часть процессов, тех самых, которые старые, и которые я защищаю по вашей версии.
Но это не значит, что проблемы не существует.
А если человек придумал проблему и ее решил, означает ли это, что проблема существует и для других людей? Кажется, что нет. Но мы смело может забиться встретиться в этой статье через 5 лет и посмотреть, что стало с вашим инструментом. При условии, что вы ничего не будете менять. То есть не добавлять информацию про кейсы, не делать для других языков, не избавляться от лишних файлов и отвратительного подхода с библиотекой, когда приходится писать дополнительную обертку для методов. Также чтобы ни в коем случае не парсили отчет аллюра, который содержит всё нужное в себе. И уж тем более не смотреть в сторону плагина для него. Ведь иначе вы будете использовать старые идеи, которые не инноваторские, а вообще чужие.
И уж точно это не делает ваш комментарий чем-то большим, чем очередной спич в стиле "раньше было лучше". Мир меняется. Инструменты тоже.
Прям в сердечко кольнули! Мой так называемый вами "спич" не был о том, что раньше было лучше. Если бы вы потратили на чтение больше времени, то заметили бы, что упоминание прошлого касалось ваших громких слов про инноваторство и прочего маркетингового bullshit'а.
Не менее смешно про какие-то новые инструменты. Проверим? Плейрайту пять лет, хотя и он не сам по себе появился. Сайпресу больше 7. Селениуму вообще страшно уже сколько. Айфрейму, который вы используете, больше 25 лет. Питону3 больше 15 лет. И самой идее с такими отчетами тоже больше 5 лет — и это только с момента публичной версии. Ну как там с новыми инструментами? Что-то не очень, не правда ли?
P.S. Критиковать легче, чем создавать.
Вам это не помешало проигнорировать вопросы и замечания по существу и заниматься эйджизмом технологий и процессов.
Спасибо, что своим комментарием подчеркнули, что в отрасли по-прежнему нужен новый взгляд на проблему.
Я подчеркивал, что ваша текущая реализация бесполезна для практического применения. И давал конкретные советы по тому, как ее улучшить. Для этого все инструменты есть. А отрасли нужны хорошие специалисты, а не любители смотреть на проблемы и решать выдуманные вещи.
P.S.: Только не придумывайте скриншот-тестирование.
Благодарю за столь эмоциональный и многословный комментарий. Видно, что мой скромный инструмент задел вас за живое, и это уже успех.
Ваш развернутый поток сознания заслуживает уважения — не каждый день можно увидеть столько страсти при обсуждении вопроса о покрытии UI. Особенно приятно, что вы нашли время написать целую стену текста, демонстрируя глубину боли, которую, судя по всему, моя работа вам причинила.
Теперь по сути:
Я рад, что вы открыли для себя различие между действиями и проверками. Поверьте, большинство людей в индустрии догадываются об этом даже без 5-страничных манифестов.
Касательно старых конференций, no-name решений и 19 минут на ознакомление: Удивительно, сколько презрения можно вложить в слова о событиях, о которых вы сами не так много знаете. К слову я лично был на этой конференции еще несколько лет назад и был в курсе про данное решение еще до того, как вы про него узнали. Не стесняйтесь, признание — первый шаг к принятию.
Ваше объяснение разницы между документацией, тест-кейсами и фактическим тестированием трогает своей наивностью. Вероятно, вы и вправду считаете, что TMS и красивые таблички спасают от багов в продакшене. Желаю удачи в этой вере.
Что касается "старых технологий" и морали пяти лет назад: Спасибо, что напомнили, что инновации для вас — это плохое слово. Видимо, в вашем мире рефакторинг под GO решает вопросы качества продукта лучше, чем инструменты контроля реального поведения тестов. Потрясающая логика.
По поводу отсутствия ассертов: Инструмент и не претендует на роль экстрасенса. Я не строю иллюзий, что могу угадать мысли тестировщика через отслеживание кликов. В отличие от некоторых, кто, судя по вашему тону, всерьез считает, что TMS отражает реальность тестирования.
В завершение хочу сказать: Если в будущем вам вновь захочется выплеснуть поток токсичности и обид за жизнь, не стесняйтесь — я рад видеть, что мой инструмент вызывает живые эмоции. А значит, он работает.
P.S.: Вместо скриншот-тестирования, как вы опасались, я, пожалуй, займусь еще одним полезным делом — выведу "coverage-психотерапию" в отдельную ветку разработки. Успех будет гарантирован — аудитория уже есть.
Измерение покрытия UI тестами