Разделы портала

Онлайн-тренинги

.
Cypress.io и GitHub Actions: пошаговое руководство
12.03.2024 00:00

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Возможно, вы уже интересовались GitHub Actions. Они кажутся продвинутой концепцией, но на самом деле это мощный и простой в освоении инструмент, который может вам пригодиться. Разберемся, как пользоваться им при прогоне тестов Cypress.

Разбираемся, что же делать

Для начала посмотрим, чего мы хотим добиться. Наша цель – прогнать Cypress-тесты, используя GitHub Actions. Чтобы сделать это, нужно взглянуть на репозиторий, с которым мы работаем. В качестве примера возьму свой проект trelloapp.

Локально тестируя приложение, я делаю две вещи.

  1. Запускаю приложение на localhost.
  2. Прогоняю тесты на этом localhost.

Чтобы сделать это на сервере GitHub Action, мне вначале нужно развернуть мой проект и установить все необходимое. Надо также определить, в каких ситуациях я хочу прогонять свои тесты (к примеру, по запросу, или при каждом новом пуше). Так потихоньку формируется план того, как будет выглядеть GitHub Action. Такие планы в GitHub Actions называются «workflows» - потоки работ.

Создание потока работ

Создадим файл потока работ. Он должен храниться в папке .github/workflows:

.github
`-- workflows
`---- tests.yml

Именно тут GitHub Actions будут искать файлы потока работ. Файлы имеют YAML-формат – рассматривайте их как рецепты для деятельности GitHub Actions. Они довольно линейны, и в них можно внедрять условную логику.

1  name: e2e-tests
2  on: [push]
3  jobs:
4    cypress-run:
5      runs-on: ubuntu-latest
6      steps:
7        - name: Checkout
8          uses: actions/checkout@v3
9        - name: Cypress run
10          uses: cypress-io/github-action@v5
11          with:
12            start: npm start

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

Вторая строка описывает событие, при котором должен выполняться определенный сценарий. Разнообразные события вроде пуш и пулл-реквеста, расписания или workflow_dispatch дают возможность вручную спровоцировать действия. Полный список – в документации GitHub Actions.

Третья строка описывает задачу или задачи, которые нужно выполнить. Тут нужно описать, что надо сделать. Если мы начинаем с нуля, то тут мы поместим npm install для установки всех зависимостей, развертки приложения и прогона тестов. Но, как мы видим, начали мы не с нуля, а используя предопределенные действия.

Это одна из суперспособностей GitHub Actions. Вместо того, чтобы делать все самостоятельно, можно воспользоваться готовым макросом, и он разберется за нас. К примеру, cypress-io/github-action@v5 прогонит npm install, правильно закэширует Cypress (чтобы в следующий раз установка была в разы быстрее), запустит приложение при помощи команды npm start и запустит команду npx cypress run. Все это – всего в четырех строчках YAML-файла.

Мы еще поговорим о разных конфигурациях Cypress GitHub Action, а сейчас вернемся чуть назад, к деталям задачи cypress-run. Параметр runs-on определяет, какой тип машины будет использоваться в наших тестах. actions/checkout@v3 может показаться странным – зачем извлекать проект, с которым мы работаем? Причина тут довольно проста. При помощи GitHub action можно сделать многое без извлечения репозитория. К примеру, отправить уведомление в Slack, как только новый код запушен в удаленную ветку.

Перейдем к использованию GitHub Actions для улучшения нашего потока работ.

Ручная инициация прогона тестов

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

1  name: e2e-tests
2  on: [worfklow_dispatch]
3  jobs:
4    cypress-run:
5      runs-on: ubuntu-latest
6      steps:
7        - name: Checkout
8          uses: actions/checkout@v3
9        - name: Cypress run
10          uses: cypress-io/github-action@v5
11          with:
12            start: npm start

Настроив файл, можно перейти в GitHub и на вкладке Actions запустить свои e2e-тесты вручную.


GitHub Actions и Cypress Cloud

Cypress Cloud (ранее Cypress Dashboard) – это сервис записи результатов тестов Cypress. Он дает обобщенное представление о тестах, чтобы эффективнее анализировать и поддерживать их. Запись результатов в сервис Cypress Cloud довольно проста. Сначала нужно подключить проект к сервису, что делается прямо в открытом режиме Cypress.

На этом этапе будет сгенерирован уникальный ключ, который используется для авторизации GitHub Actions – теперь они могут взаимодействовать с Cypress Cloud. Скопируйте ключ и добавьте его в окружение проекта GitHub как CYPRESS_RECORD_KEY.

И на последнем шаге нужно отредактировать файл потока работ:

1  name: e2e-tests
2  on: [push]
3  jobs:
4    cypress-run:
5      runs-on: ubuntu-latest
6      steps:
7        - name: Checkout
8          uses: actions/checkout@v3
9        - name: Cypress run
10          uses: cypress-io/github-action@v5
11          with:
12            start: npm start
13            record: true
14          env:
15            CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

Это позволит записывать результаты в Cypress Cloud и добавит ключ Cypress в окружение, чтобы прогон Cypress мог пользоваться им.

Запись результатов в Cypress Cloud дает вам потрясающие возможности. Можно посмотреть на скриншоты и видео прогона Cypress, помогающие дебажить тесты, или взглянуть на долгосрочную аналитику, проверяя состояние здоровья своего тест-набора. К тому же тут есть ряд полезных интеграций. Если вы не хотите постоянно переключаться между Cypress Cloud и GitHub, отправляйте результаты тестов прямо в GitHub.


После настройки интеграции результаты тестов будут отправлены прямо в диалог пулл-реквеста, а также вам на почту.


Интеграция GitHub также станет частью проверок пулл-реквеста, и если тесты упали, вы можете предотвратить слияние такого реквеста.


Параллельный запуск тестов

Cypress Cloud позволяет запускать тесты параллельно. Когда вы настроили проект, довольно легко разделить тесты между несколькими машинами. Файл конфигурации будет выглядеть так:

1  name: e2e-tests
2  on: [push]
3  jobs:
4    cypress-run:
5      runs-on: ubuntu-latest
6      strategy:
7        fail-fast: false
8        matrix:
9          containers: [1, 2, 3]
10      steps:
11        - name: Checkout
12          uses: actions/checkout@v2
13        - name: Cypress run
14          uses: cypress-io/github-action@v4
15          with:
16            start: npm start
17            record: true
18            parallel: true
19          env:
20            CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

Эта настройка поднимет три машины и параллельно запустит все наши шаги. Флаг parallel: true убеждается, что прогон тестов взаимодействует с Cypress Cloud, и разделяет все тесты между машинами. Cypress Cloud также возьмет на себя автоматическую балансировку нагрузки тестов, чтобы они занимали минимально возможное время.

Флаг fail-fast убеждается, что GitHub не прекратит задачу, если какой-то тест упал. Если он стоит в true, вы рискуете зависанием тестов в Cypress Cloud. Если вам нужно, чтобы тесты прекращали работу после падения, это можно настроить в настройках проекта Cypress Cloud. Сервис даже позволяет вам указать количество тестов, которые должны спровоцировать отмену прогона.


Параллельный запуск без Cypress Cloud

Когда я писал эту статью, Глеб Бахмутов выпустил плагин, позволяющий запускать тесты параллельно без Cypress Cloud. Плагин делит ваши спеки между параллельными машинами так же, как и Cypress Cloud. Конфигурация довольно проста.

1  name: e2e-tests
2  on: [push]
3  jobs:
4    cypress-run:
5      runs-on: ubuntu-latest
6      strategy:
7        fail-fast: false
8        matrix:
9          containers: [1, 2, 3]
10      steps:
11        - name: Checkout
12          uses: actions/checkout@v3
13        - name: Cypress run
14          uses: cypress-io/github-action@v5
15          with:
16            start: npm start
17          env:
18            SPLIT: ${{ strategy.job-total }}
19            SPLIT_INDEX: ${{ strategy.job-index }}

Для передачи GitHub нужной информации вам нужно настроить переменные окружения SPLIT и SPLIT_INDEX. Таким образом каждому процессу будут назначены нужные спеки. Он примет решение автоматически, но это можно настроить – информация есть в файле README. Изящное решение для ситуаций, когда вам не нужен Cypress Cloud, или же уже есть дашборд отчетности.

Обсудить в форуме