Comments 10
Спасибо за статью. Здорово, что российское комьюнити Cypress активно растет. По скриншот-тестированию возникло несколько вопросов:
- По вашему опыту, проблемы с версткой общие для всех браузеров? Проверки в Хроме лучше, чем ничего, но по моему опыту — верстка очень часто едет в FF, Safari и IE11. Последние два Cypress не поддерживает, и это проблема. Рассматривали какие-нибудь альтернативы для кросс-браузерного визуального тестирования?
- Какая у вас процедура обновления скриншотов? Например, я поднял ПР с изменением размера текста на странице. Визуальный CI-ран упал. Я сравнил скриншоты (кстати, какой репортер используете?), вижу, что ченжи правильные. Нужно руками переснимать? Или запустить отдельную джобу по пересъему скриншотов? Или есть волшебная кнопка «Approve» возле каждого скриншота?
- Скриншоты лежат в гите с проектом? Не раздувается размер проекта из-за этого? Или храните их в lfs?
0
Привет! Спасибо, отличные вопросы.
- На самом деле по анализу проблем с прода, проблемы именно в конкретном браузере редкие (посмотрел например последние 10, и в них вообще ничего про то, что сломалось именно в safari или в ie11), но как бы то ни было, от самого ручного тестирования в плане приемки мы не отказывались, и на этапе приемки могут выявляться такие проблемы, мы их сразу закрываем и этого в принципе хватает, так как такие кейсы на регресс не попадают, а лично целью нашей команды как раз и было сокращение регресса
- На данный момент просто в артефакты агента в отдельную папку кладем diff и смотрим что сломалось, также сейчас временно добавили решение по сохранению актуальных скриншотов, (пришлось слегка извернуться, так как cypress-image-snapshot такой возможности из коробки не дает) и в случае если действительно нужно поменять скриншот, то просто из артефактов берем актуальный и подменяем его у себя в ПРе, но на самом деле это очень редко происходит, так как обычно еще до открытия ПРа мы понимаем примерно где могут развалиться скриншоты и сразу их обновляем ручками, но в качестве дальнейшего развития точно будем думать над темой автоматизации обновления скриншотов в CI, пока просто не так горит
- Да, пока храним в проекте, каких-то особых проблем с размером еще не ощутили, скриншоты весят по 100 кБ, но git lfs думаю можно легко заинтегрировать с этой темой, каких-то проблем быть не должно, изначально мы планировали начать сразу с использования git lfs, но решили сначала столкнуться с проблемой, а уже потом его докручивать
0
Разве Angular не позволяет отключить анимацию? Такое было в AngularJS и странно, что они не сделали тоже самое в новой версии Angular
0
Я, к сожалению, не застал времена AngularJS, погуглил как там отключалась анимация в runtime, и насколько я знаю похожего инструмента в Angular из коробки нет, думаю что можно переопределить AnimationDriver ради этого, но мы все таки сошлись на том, чтобы тестировать приложение в таком же формате, в каком оно используется в production, так как в принципе для отключения анимации есть хаки, типо transition: 0s и тому подобные
0
Спасибо за описание некоторых проблем при скриншотном тестировании и возможных путей их решения — но для чего они, собственно? Кроссбраузерность на Cypress не проверить, и кроссплатформенность верстки тоже, хотя из-за особенностей браузеров и систем могут быть значительные различия в отображении. Визуальное сравнение может помочь только в кейсах, когда возникло неожиданное влияние одних стилей на другие (неправильно указаны слои, совпадение имен классов на глобальном уровне, изменившийся при prod-оптимизации порядок следования стилей), но по большей части подобные баги выявятся на ручном feature-тестировании, а при грамотных подходах их вообще не должно возникнуть. Бывает, конечно, что в одном месте поменяли — и в очень далеком аукнулось, что можно выявить только полноценным регрессом, но создать систему скриншотного тестирования, способную отловить подобное — настолько сложное и муторное занятие, что вряд ли оправданно.
0
Ну на самом деле, когда только внедряли скриншот-тестирование, приседать приходилось много, у нас часто в самом начале ломался pipeline в CI из-за нестабильного скриншота, что как раз не ускоряло доставку, а замедляло. Но вот сейчас, имея полностью стабильные тесты, могу сказать, что на скриншотах мы отловили кучу багов (больше чем тестами без скриншотов), как своих, так и при обновлении версии пакетов сторонних библиотек. Приведу пример, который как раз случился пару дней назад — есть абстрактный компонент с таймером обратного отсчета, который может использоваться в разных местах, были слегка подправлены его стили, в результате чего в каких-то кейсах использования содержимое компонента переставала вмещаться на 1 строке и переносилось на 2, и отловили это как раз во время скриншот-тестов, ручками искать такие баги кажется каким-то насилием над тестировщиком. Как раз по сути твой описанный случай — поправили в одном месте, аукнулось в другом. Ну и в принципе могу сказать, что сейчас сложность представить наш pipeline в CI без скриншот-тестов, главное начать, тем более в статье постарался описать все проблемы, с которыми мы столкнулись.
0
привет! Спасибо за статью! Как вы параллелите выполнение тестов?
0
Привет, сейчас сделали самый простой вариант параллельности, имеем два скрипта в package.json, первый запускает тесты с параметром testFiles установленным на папку с первой частью тестов, а второй запускает тесты с параметром ignoreTestFiles с таким же значением как и в первом скрипте (про параметры подробнее здесь docs.cypress.io/guides/references/configuration.html#Folders-Files)
0
Владимр, привет! спасибо за статью, многому научился. Насколько я понял вы же мокаете все данные при скриншот тестировании? Иначе flaky тесты будут каждый спринт
0
Sign up to leave a comment.
Пишем интеграционные тесты на фронтэнд и ускоряем релизы