Пишем интеграционные тесты на фронтэнд и ускоряем релизы

Привет, сейчас сделали самый простой вариант параллельности, имеем два скрипта в package.json, первый запускает тесты с параметром testFiles установленным на папку с первой частью тестов, а второй запускает тесты с параметром ignoreTestFiles с таким же значением как и в первом скрипте (про параметры подробнее здесь docs.cypress.io/guides/references/configuration.html#Folders-Files)

Пишем интеграционные тесты на фронтэнд и ускоряем релизы

Привет! Да, сидим по сути на полных моках и практически во всех тестах стараемся мокать дату, даже если изначально кажется, что это нужно, так как уже были кейсы, что 1 января встречаешь развалившиеся тесты из-за сменившегося года)

Пишем интеграционные тесты на фронтэнд и ускоряем релизы

Ну на самом деле, когда только внедряли скриншот-тестирование, приседать приходилось много, у нас часто в самом начале ломался pipeline в CI из-за нестабильного скриншота, что как раз не ускоряло доставку, а замедляло. Но вот сейчас, имея полностью стабильные тесты, могу сказать, что на скриншотах мы отловили кучу багов (больше чем тестами без скриншотов), как своих, так и при обновлении версии пакетов сторонних библиотек. Приведу пример, который как раз случился пару дней назад — есть абстрактный компонент с таймером обратного отсчета, который может использоваться в разных местах, были слегка подправлены его стили, в результате чего в каких-то кейсах использования содержимое компонента переставала вмещаться на 1 строке и переносилось на 2, и отловили это как раз во время скриншот-тестов, ручками искать такие баги кажется каким-то насилием над тестировщиком. Как раз по сути твой описанный случай — поправили в одном месте, аукнулось в другом. Ну и в принципе могу сказать, что сейчас сложность представить наш pipeline в CI без скриншот-тестов, главное начать, тем более в статье постарался описать все проблемы, с которыми мы столкнулись.

Пишем интеграционные тесты на фронтэнд и ускоряем релизы

Я, к сожалению, не застал времена AngularJS, погуглил как там отключалась анимация в runtime, и насколько я знаю похожего инструмента в Angular из коробки нет, думаю что можно переопределить AnimationDriver ради этого, но мы все таки сошлись на том, чтобы тестировать приложение в таком же формате, в каком оно используется в production, так как в принципе для отключения анимации есть хаки, типо transition: 0s и тому подобные

Пишем интеграционные тесты на фронтэнд и ускоряем релизы

Привет! Спасибо, отличные вопросы.

1. На самом деле по анализу проблем с прода, проблемы именно в конкретном браузере редкие (посмотрел например последние 10, и в них вообще ничего про то, что сломалось именно в safari или в ie11), но как бы то ни было, от самого ручного тестирования в плане приемки мы не отказывались, и на этапе приемки могут выявляться такие проблемы, мы их сразу закрываем и этого в принципе хватает, так как такие кейсы на регресс не попадают, а лично целью нашей команды как раз и было сокращение регресса
2. На данный момент просто в артефакты агента в отдельную папку кладем diff и смотрим что сломалось, также сейчас временно добавили решение по сохранению актуальных скриншотов, (пришлось слегка извернуться, так как cypress-image-snapshot такой возможности из коробки не дает) и в случае если действительно нужно поменять скриншот, то просто из артефактов берем актуальный и подменяем его у себя в ПРе, но на самом деле это очень редко происходит, так как обычно еще до открытия ПРа мы понимаем примерно где могут развалиться скриншоты и сразу их обновляем ручками, но в качестве дальнейшего развития точно будем думать над темой автоматизации обновления скриншотов в CI, пока просто не так горит
3. Да, пока храним в проекте, каких-то особых проблем с размером еще не ощутили, скриншоты весят по 100 кБ, но git lfs думаю можно легко заинтегрировать с этой темой, каких-то проблем быть не должно, изначально мы планировали начать сразу с использования git lfs, но решили сначала столкнуться с проблемой, а уже потом его докручивать