Комментарии 22
Современные отчеты покрытия в ряде случаев довольно бесполезны, а способы их измерения подходят в основном лишь разработчикам.
К счастью, "покрытие тестами" — бесполезная и даже вредная метрика. Поэтому о ней можно не беспокоиться, и тем более об отчётах.
Слышал, что код писать тоже вредно…
способы их измерения подходят в основном лишь разработчикам
Хо-хо! Чувствую в формулировке отголоски классовой ненависти пополам с расовой сегрегацией. Я помню, что когда у общества нет цветовой дифференциации штанов, то нет цели. Но всё равно звучит не очень.
Метрика эта не вредная, сама по себе. Вот чего не надо, так это экстремальничать и гнаться за метриками. И ещё очень аккуратно надо выбирать единицы измерения метрик, а то получится, что "end2end тесты покрывают 100% сайта" — это фигня полная. А вот, например "end2end тесты покрывают 25 основных сценариев поведения пользователя" — это же совсем другое. (только не докапывайтесь до того, как они хорошо покрывают сценарии, а то в рекурсию войдём :)
Статью не читал, но пролистал слайды и увидел жуткое число про проценты покрытия.
Все тесты, которые я видел в жизни, делились на следующие большие категории:
- Тесты, которых не было.
- Очень небольшое количество тестов для end to end сценариев, написанных много позже разработки. Редко, но метко.
- Очень плохие и бесполезные тесты, про которые было заявлено большое покрытие, а по факту они только мешались, тормозили разработку и ничего не делали.
Откуда берутся все эти люди, которые нафигачили покрытие 40, 50, 60, 160 процентов кода? Зачем им это нужно?
Из всех людей, тестировщики внушают какой-то глубинный животный страх. Там в одном месте собирается куча людей, оперирующих 40+ покрытиями. Непонятное всегда страшно, и я ничерта не понимаю, чем они занимаются, как будто ты оказался в Австралии, а там собакоголовые люди ходят на руках вверх ногами. Чо у вас там происходит? :-)
Интересно, а какие тесты вы писали? =)
Покрытие, как отметили комментарием выше, не всегда важно само по себе. Голая цифра в 100% ничего не значит, кроме того, что вы потратили много времени, чтобы ее добиться.
Думаю, что покрытие может помочь отвечать на вопросы:
— Что мы сделали, чтобы у нас не было багов?
— Что мы можем сделать, чтобы рефакторить код было не больно?
— Как дать понять руководству или клиенту, что приложение работает ок?
— Как самому понять, что приложение работает? =)
— многие другие вопросы
А что мы можем сделать, чтобы рефакторить было не больно?
Ну вот допустим, взяли мы какой-то UI, заавтоматизировали там все выше крыши, написали тесты на трех селениумах и четырех пупетирах.
И тут приходит твой индийский хозяин, сир Джо, и говорит: ребятки, вы знаете, с этой осени интерфейс на выпадающих списках — совершенно не модный в мире интерфейсов. У нас сайт выглядит как из начала 2000-х. Выпиливайте свои списки и давайте сделаем все то же самое, но в виде отдельных окон с дизайном в стиле Material. И кстати, перепишите все на Vue тогда уж, чего позориться с jQuery
Вроде кода для миграции там совсем немного, но все наши UI тесты, достигнутые непосильным трудом, превратились в тыкву. Особенно те, которые были записаны всевозможными мастерами, записывающими последовательность действий.
Мой поинт в том, что даже тупо джаваскрипт фреймворки меняются быстрее, чем ты осознаешь их функциональность!
— Как самому понять, что приложение работает? =)
Посмотреть в почту саппорта, твиттер по хэштегу "$имя_твоего_продукта говно", и так далее. Если там по какой-то проблеме собралось достаточно воплей — надо чинить. Иначе не надо. Как тебе такое?
(Если не ошибаюсь, это было в какой-то из книжек от создателей Basecamp)
Слушайте, ну если у вас какая-то суперпопулярная компонента используется, но тестируется каждый раз по-разному, то проблема в том, как у вас тесты написаны.
Тестов не должно быть 100500 тысяч, особенно end2end.
Менюшку (как компоненту) в одном месте проверили — и этого достаточно, чтобы сказать, что "менюшка окей". А если вам надо каждый раз проверять, что в менюшку правильные данные прилетают и вы это каждый раз селениумом проверяете, то это же стрельба из пушки по воробьям.
Вообще, end2end тесты написать-то просто, а писать их так, чтобы не было больно потом — сложно.
Чтобы не было больно рефакторить, нужна спланированная стратегия тестирования и сбалансированный подход в пирамиде тестов. Там, где можно, тестируйте с помощью моков, заглушек, затычек. Где нельзя или не нужно — ну вот переиспользуйте компоненты :)
Ваш кэп.
PS
Метрика покрытия end2end тестами кода мне лично тоже не нравится, но Артём явно говорит о другом — как визуально дать понять, что какие-то места в огромном проекте покрыты / не покрыты тестами. Мы такое пробовали несколько лет назад, не зашло. Но инструментарий надо выбирать под проект, кому-то нужна отвёртка, а кому-то — рубанок.
Дальше я сообщаю, что при большом количестве тестов и участников команды встает вопрос о том, какие тесты есть, а каких нет.
Имея на входе эти два пункта я делаю следующий вывод: покрытие само по себе интересно, но текущая его реализация (через линии кода) не работает.
Следом я предлагаю сдалеать следующий трюк: за основу «покрытия» беру более высокоуровневую составляющую продукта, а не строку кода. Например:
1. вызовы Rest API
2. конкретный элемент на странице
3. твой вариант
И в конце я показываю, как могло бы выглядеть покрытие в этом случае.
И теперь вопрос, с чем ты споришь?
Если ты считаешь, что покрытие по строкам не работает, я с тобой согласен.
Если тебе не важно покрытие, то не делай так. Возможно у нас отличаются условия.
Если тебе не нравится конкретная реализация, то расскажи как бы ты это сделал.
vbrekelov — я, возможно, что-то пропустил в статье. Как именно вы собираете статистику использования dom-элементов из тестов? Эта встроенная фича у вас во фреймворке тестирования? Или что-то самодельное написали?
Если менеджер спросит, что у нас покрыто, я открою табличку и покажу, какие фичи покрыты
Ваши менеджеры такое спрашивают? Если да, то зачем? Что они делают с этой информацией, для каких решений им это нужно?
Наличие этой информации помогает им понимать какая часть продукта тестируется и/или не тестируется, точнее составлять планы на расширение покрыти и расставлять приоритеты.
Эти инструменты просто визуализируют то, что проверяется в тестах. Ровно как джира визуализирует то, что будет разрабатываться в ближайшее время.
точнее составлять планы на расширение покрытия
Верно ли я понял, что карта покрытия тестами приводит к появлению задач, вида «у нас вон там совсем мало тестов, надо написать еще»?
Есть ли в вашем проекте другие сценарии использования этой инфы?
Там есть ссылки в конце статьи:
swagger-coverage
locators-hotspots-chrome-plugin
Можно отследить когда будет готово. Но, может eroshenkoam еще подскажет тут.
Кстати, можно самим поконтрибьютить =)
Визуализация покрытия автотестами