Pull to refresh

Comments 10

Спасибо за статью. Здорово, что российское комьюнити Cypress активно растет. По скриншот-тестированию возникло несколько вопросов:

  1. По вашему опыту, проблемы с версткой общие для всех браузеров? Проверки в Хроме лучше, чем ничего, но по моему опыту — верстка очень часто едет в FF, Safari и IE11. Последние два Cypress не поддерживает, и это проблема. Рассматривали какие-нибудь альтернативы для кросс-браузерного визуального тестирования?
  2. Какая у вас процедура обновления скриншотов? Например, я поднял ПР с изменением размера текста на странице. Визуальный CI-ран упал. Я сравнил скриншоты (кстати, какой репортер используете?), вижу, что ченжи правильные. Нужно руками переснимать? Или запустить отдельную джобу по пересъему скриншотов? Или есть волшебная кнопка «Approve» возле каждого скриншота?
  3. Скриншоты лежат в гите с проектом? Не раздувается размер проекта из-за этого? Или храните их в lfs?
Привет! Спасибо, отличные вопросы.

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