Комментарии 6
У вас в последнее время сайт как-то странно работает, фризится на переходах. Иногда некоторые элементы появляются позже, что сдвигает вертикальную позицию, и бывает мисклик.
Вы в одном тесте пишите сразу кучу модификаторов состояний. В итоге количество скринов возрастает экспоненциально. В примере у вас лишь удвоение дважды, но как в итоге после полугода использования? Наверняка ж есть и компоненты у которых и самих изменяющихся свойств сильно больше, чем 2 и состояний у каждого из них – тоже может быть сильно больше чем 2. Писать явно проще, но добавление 1 свойства и всех его значений может сильно замедлить тесты. Можете подсказать по практике, сколько у вас больших компонентов, сколько в них вариантов, сколько в итоге времени гоняются тесты?
И еще вопрос: насколько удобно держать столько вариантов в 1 тесте? в итоге получается по сути 1 мегатест на 1 компонент. Если что-то падает, то насколько легко разобраться, куда идти и что править?
Мы не пишем один большой тест, покрывающий все возможные кейсы. Обычно пишем несколько тестов с группой параметров, у которых сильная взаимосвязь. Например,
style + isDisabled + isPressed, чтобы проверить все варианты покрасок компонента.
На текущий момент количество картинок для каждого компонента не больше 130. Почти все наши snapshot-тесты — это unit-тесты, поэтому время прогона увеличилось на несколько секунд. Если добавить UI-тесты, то счёт уже пойдёт на минуты, так как UI-тесты медленные.Про мегатест уже ответил в пункте 1. Если что-то падает, то обычно смотрим на дифф в гите, там уже примерно понятно, что сломалось. Если нужны детали - приходится копаться в именах, что да, не очень удобно. Но на практике это приемлемо т.к. тесты ломаются у нас довольно редко. Ещё была идея формировать одну большую картинку из нескольких состояний, но здесь можем столкнуться с проблемой частых обновлений картинки. Поэтому пока остановились на текущем варианте с множеством мелких картинок.
хорошо понятно.
Зря я "мегатест" упомянул в вопросе. Давайте забудем про него.
Конкретные примеры:
Вот у вас последний тест - там в 1 тесте сразу 2 скриншота генерируется.
Пример с "all" - там в 1 тесте вообще 4 скриншота проверяется.
Если падает 1 тест, в котором сразу с десяток (или 2 или 4, неважно, главное – что не одна) картинок генерируется, насколько просто искать потом место, которое нужно править?
______________
Кстати, "не больше 130 картинок на компонент", а тестов при этом сколько на компонент?
Скриншот-тесты - это не юниты, хоть они и близки к юнитам. Для юнитов необходимое условие – это изоляция. Если для скриншотов по аналогии использовать изоляцию, то в 1 тесте должна быть 1 картинка. Но мне, например, понятно, что скриншоты – все же выше юнитов, и поэтому, возможно, это правило не должно выполняться прям полностью. Вы его не выполняете. Но мне хочется понять, какие это издержки привносит...
Пока вы отметили, что приходится копаться в именах, но это происходит нечасто... Может быть что-то еще?
сколько тестов на компонент
В среднем 3-4 теста на компонент. Картинок в одном тесте порядка двух-трёх десятков. Например, у нас самый богатый на свойства компонент это Button. У него общее количество сгенерированных картинок - 120, тестов - 6, в одной пачке примерно 20 картинок.
насколько просто искать место которое нужно править.
А названия отдельных тестов и их структура тут мало решают на самом деле при починке. Проще сразу пробежаться глазами по диффу картинок. По нему сходу более-менее всё понятно.
На практике это обычно выглядит так:
На CI неожиданно упали snapshot-тесты.
Прогоняем локально с включенным
record: true. Фреймворк перезаписывает изменившееся.Смотрим по гиту изменившиеся картинки. Тот же Fork (гит клиент), например, удобен тем, что умеет diff картинок делать разными способами. Можно любые сдвиги до пикселей разглядеть. Тут уже обычно понятно, что сломалось в 99% случаев. Ниже приложил пару скринов из Fork'а.
Если изменения логичные и оправданные - просто коммитим вновь сгенерированные картинки.
Если неоправданные и что-то сломалось - идем править.
Если непонятно какие изменения в коде сломали тесты - полезно опять же гитом сделать diff кода от последнего стабильного состояния для папки с кодом компонента - тут ловится еще 1% сложных случаев.
Если все равно непонятно - тогда это уже совсем тяжелый случай, и нужно копать отдельно, сравнивать параметры и т.д.
Когда snapshot-тесты ожидаемо ломаются в процессе изменения самого компонента, мы просто генерируем новые картинки. А неожиданно snapshot-тесты у нас ломаются в худшем случае раз в несколько месяцев. Поэтому это совсем ненапряжно.
Если бы поток падений был сильнее, мы бы скорее в сторону генерации на CI более удобных репортов смотрели, чтобы сразу можно было посмотреть diff картинок.
Snapshot-тесты для дизайн-системы hh.ru