Визуализация покрытия автотестами

[ip1981]

Современные отчеты покрытия в ряде случаев довольно бесполезны, а способы их измерения подходят в основном лишь разработчикам.

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

[vbrekelov]

Я правильно понимаю, что вы предлагаете не беспокоится обо всем вредном? =)
Слышал, что код писать тоже вредно…

[tundrawolf_kiba]

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

[green_hippo]

способы их измерения подходят в основном лишь разработчикам

Хо-хо! Чувствую в формулировке отголоски классовой ненависти пополам с расовой сегрегацией. Я помню, что когда у общества нет цветовой дифференциации штанов, то нет цели. Но всё равно звучит не очень.

[tolkkv]

Хо-хо. Классовую конкуренцию легко спутать с классовой ненавистью :) Надеюсь, что это всё же был вызов, а не разжигание :)

[bbidox]

Метрика эта не вредная, сама по себе. Вот чего не надо, так это экстремальничать и гнаться за метриками. И ещё очень аккуратно надо выбирать единицы измерения метрик, а то получится, что "end2end тесты покрывают 100% сайта" — это фигня полная. А вот, например "end2end тесты покрывают 25 основных сценариев поведения пользователя" — это же совсем другое. (только не докапывайтесь до того, как они хорошо покрывают сценарии, а то в рекурсию войдём :)

[olegchir]

Статью не читал, но пролистал слайды и увидел жуткое число про проценты покрытия.

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

• Тесты, которых не было.
• Очень небольшое количество тестов для end to end сценариев, написанных много позже разработки. Редко, но метко.
• Очень плохие и бесполезные тесты, про которые было заявлено большое покрытие, а по факту они только мешались, тормозили разработку и ничего не делали.

Откуда берутся все эти люди, которые нафигачили покрытие 40, 50, 60, 160 процентов кода? Зачем им это нужно?

Из всех людей, тестировщики внушают какой-то глубинный животный страх. Там в одном месте собирается куча людей, оперирующих 40+ покрытиями. Непонятное всегда страшно, и я ничерта не понимаю, чем они занимаются, как будто ты оказался в Австралии, а там собакоголовые люди ходят на руках вверх ногами. Чо у вас там происходит? :-)

[vbrekelov]

«Не читал, но осуждаю».

Интересно, а какие тесты вы писали? =)
Покрытие, как отметили комментарием выше, не всегда важно само по себе. Голая цифра в 100% ничего не значит, кроме того, что вы потратили много времени, чтобы ее добиться.
Думаю, что покрытие может помочь отвечать на вопросы:
— Что мы сделали, чтобы у нас не было багов?
— Что мы можем сделать, чтобы рефакторить код было не больно?
— Как дать понять руководству или клиенту, что приложение работает ок?
— Как самому понять, что приложение работает? =)
— многие другие вопросы

[olegchir]

А что мы можем сделать, чтобы рефакторить было не больно?

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

И тут приходит твой индийский хозяин, сир Джо, и говорит: ребятки, вы знаете, с этой осени интерфейс на выпадающих списках — совершенно не модный в мире интерфейсов. У нас сайт выглядит как из начала 2000-х. Выпиливайте свои списки и давайте сделаем все то же самое, но в виде отдельных окон с дизайном в стиле Material. И кстати, перепишите все на Vue тогда уж, чего позориться с jQuery

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

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

— Как самому понять, что приложение работает? =)

Посмотреть в почту саппорта, твиттер по хэштегу "$имя_твоего_продукта говно", и так далее. Если там по какой-то проблеме собралось достаточно воплей — надо чинить. Иначе не надо. Как тебе такое?

(Если не ошибаюсь, это было в какой-то из книжек от создателей Basecamp)

[bbidox]

Слушайте, ну если у вас какая-то суперпопулярная компонента используется, но тестируется каждый раз по-разному, то проблема в том, как у вас тесты написаны.
Тестов не должно быть 100500 тысяч, особенно end2end.
Менюшку (как компоненту) в одном месте проверили — и этого достаточно, чтобы сказать, что "менюшка окей". А если вам надо каждый раз проверять, что в менюшку правильные данные прилетают и вы это каждый раз селениумом проверяете, то это же стрельба из пушки по воробьям.
Вообще, end2end тесты написать-то просто, а писать их так, чтобы не было больно потом — сложно.
Чтобы не было больно рефакторить, нужна спланированная стратегия тестирования и сбалансированный подход в пирамиде тестов. Там, где можно, тестируйте с помощью моков, заглушек, затычек. Где нельзя или не нужно — ну вот переиспользуйте компоненты :)
Ваш кэп.

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

[eroshenkoam]

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

Дальше я сообщаю, что при большом количестве тестов и участников команды встает вопрос о том, какие тесты есть, а каких нет.

Имея на входе эти два пункта я делаю следующий вывод: покрытие само по себе интересно, но текущая его реализация (через линии кода) не работает.

Следом я предлагаю сдалеать следующий трюк: за основу «покрытия» беру более высокоуровневую составляющую продукта, а не строку кода. Например:
1. вызовы Rest API
2. конкретный элемент на странице
3. твой вариант

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

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

[amakhrov]

vbrekelov — я, возможно, что-то пропустил в статье. Как именно вы собираете статистику использования dom-элементов из тестов? Эта встроенная фича у вас во фреймворке тестирования? Или что-то самодельное написали?

[eroshenkoam]

Мы использовали обычный Listener, который есть в каждом фреймворке. Во время действия с элементом мы берем полный селектор этого элемента и страницу, на которой было выполнено действие.

[leorush]

А как быть в случае SPA?
Или если у элемента могут быть различные состояния?

[eroshenkoam]

В данном случае менеджер — это роль. Можно подразумевать руководителя тестирования, менеджера продукта и всех тех, кому интересно состояние продукта с точки зрения тестирования.
Наличие этой информации помогает им понимать какая часть продукта тестируется и/или не тестируется, точнее составлять планы на расширение покрыти и расставлять приоритеты.
Эти инструменты просто визуализируют то, что проверяется в тестах. Ровно как джира визуализирует то, что будет разрабатываться в ближайшее время.

[eroshenkoam]

1. Скорее «это не покрыто» или «это недопокрыто». Например частный кейс — проверка под авторизацией или с конкретными тестовыми данным.
2. Еще пытаемся использовать когда баг пропущен и нужно посмотреть «тестировалось это или нет»

[eroshenkoam]

ага

[kortik]

Плагин, мега полезная штука, по крайней мере в нашей компании) Я так понимаю он еще на стадии разработки?

[vbrekelov]

Для Swagger уже работает, а вот плагин для Chrome еще в разработке, да.
Там есть ссылки в конце статьи:
swagger-coverage
locators-hotspots-chrome-plugin
Можно отследить когда будет готово. Но, может eroshenkoam еще подскажет тут.

Кстати, можно самим поконтрибьютить =)