Админ сайта познакомится с девушкой из Екатеринбурга. Напиши о себе/оставь контакт через форму обратной связи, заинтересуешь - свяжусь с тобой.

Интеграция Cypress в CI Gitlab. Общие концепции

Введение

Здравствуй, дорогой тестировщик. В этой серии заметок я постараюсь собрать всю-всю-всю информацию по интеграции Cypress тестов в CI гитлаба. В теории должно получиться что-то между гайдом и справочником чтобы и начинающие смогли сделать все самостоятельно, пользуясь только этим руководством, и более опытные (скорее всего это буду я сам) смогли повторить некоторые темы, если что-то забылось.

Зачем все это?

В определенный момент встала задача автоматизировать регрессионные тесты проекта ХХХ. В принципе, это была не особо проблема — Cypress давно был известен, просто нужно было использовать этот мощный, но довольно тяжелый инструмент по полной и, желательно, так, чтобы такие тесты нельзя было бы заменить простыми скриптами в Kotlin. Иначе почему бы просто не написать кучу скриптов?

В определенны момент пришла идея граничащая с гениальностью: зачем запускать автоматические тесты вручную, если это тоже можно автоматизировать? На пути решения этой задачи всплыло много подводных камней, нюансов и неочевидных особенностей, связанных как с конкретными инструментами, так и с их взаимодействием и даже совсем с ними не связанными, но влияющими. Особенностей так много, что едва умещаются в голове, рискуют забыться, не будучи структурированными и записанными.

Основные концепции

Тестирование скриншотами — мало проверить наличие/отсутствие элемента. Нужно знать не произошел ли сбой в их верстке или взаимном расположении. Проверяем визуал.

Контейнеризация и легкость запуска — отрисовка шрифтов/элементов должна происходить одинаково на любой машине. Разработчики должны быть избавлены от необходимости что-то устанавливать, разбираться в тестах и т.д. Запуск тестов должен быть возможен одной простой командой.

Защищенность от проблем с бэком — т.к. проверяем только фронт, тесты следует изолировать от бэкенда и возможных проблем с ним.

Информативность — из контейнера Docker результаты должны передаваться в ранер Gitlab. Мы должны иметь возможность с ними ознакомиться.

Автоматизация — всю скучную и нудную работу выполняет машина, для этого она и сделана. Тестировщик пишет тесты, поддерживает их, смотрит что и где пошло не так, а не тыкает на кнопочки запуска.

Что потребуется перед началом

  1. Базовые знания Docker, хотя бы пройденный официальный гайд.
  2. Кое-какие навыки в написании тестов Cypress.
  3. Более-менее понимать что такое CI/CD и как работают пайплайны.
  4. Базовые навыки в разработке, приложение на один экран, инпут и пару кнопок по гайдам из интернета — достаточно.
  5. Базовые знания линтеров, прочти страницу на Википедии, если впервые слышишь, пригодится.

Структура статей

Статьи будут состоять из трех частей:

  1. Пространные рассуждения на тему.
  2. Теоретическая часть, дающая более полное представление о предмете статьи.
  3. Прикладная часть с кусками кода и подробным их разбором.

Связанные статьи

0
Нет комментариев. Ваш будет первым!