Возможно, вы задавались вопросами о GitHub Actions. Он кажется сложным, но на самом деле это мощный и простой в освоении инструмент, который может вам помочь. Давайте рассмотрим, как использовать его для запуска Cypress тестов.
Формируем понимание того, что нужно делать
Давайте сначала посмотрим, чего мы пытаемся достичь. Цель состоит в том, чтобы запустить тесты в Cypress с помощью GitHub Actions. Для этого нужно взглянуть на репозиторий, с которым мы работаем. В качестве примера я буду использовать свой проект trelloapp.
Всякий раз, когда я тестирую приложение локально, мне нужно сделать две вещи:
запустить приложение на localhost
запустить тесты на localhost.
Для того, чтобы сделать это на сервере GitHub Action, сначала нужно запустить проект и установить все необходимое. Также нужно определить, в каких случаях мы хотим запускать тесты (например, запускать их по требованию или каждый раз, когда появляется новый код). Так постепенно формируется план того, как будут выглядеть GitHub Action. В GitHub Actions эти планы называются "workflows".
Создание workflow
Теперь давайте создадим файл workflow. Он будет располагаться в папке .github/workflows:
Именно здесь GitHub Actions будет искать workflow файлы. Это файлы формата YAML, их можно рассматривать как набор правил, описывающих, что должен делать GitHub Actions. Они, как правило, довольно линейны, хотя в них можно написать условную логику.
name: e2e-tests
on: [push]
jobs:
cypress-run:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cypress run
uses: cypress-io/github-action@v5
with:
start: npm start
Давайте разберем, что происходит в этом файле. В первой строке мы даем действию имя. Оно может быть любым, но лучше, чтобы было описательным.
Во второй строке определяем событие, по которому должен выполняться данный сценарий. Существует множество различных событий, таких как push
, pull_request
, schedule
или workflow_dispatch
, которые позволяют запускать действие вручную. Полный список можно найти в документации GitHub Actions.
Третья строка определяет задачу или задачи, которые необходимо выполнить. Здесь мы должны определить, что нужно сделать. Если бы мы начинали с нуля, то здесь мы бы выполнили npm install
для установки всех зависимостей, запуска приложения и проведения тестов на нем. Но, как вы видите, мы не начинаем с нуля, а используем заранее определенные действия.
Это одна из суперспособностей GitHub Аctions. Вместо того, чтобы создавать все самим, мы можем использовать ранее созданные макросы. Например, cypress-io/github-action@v5 запустит npm install
, правильно кэширует Cypress (чтобы в следующий раз установка прошла быстрее), запустит приложение с помощью команды npm start
и выполнит команду npx cypress run
. И все это с помощью всего четырех строк в YAML-файле.
Мы скоро поговорим о различных конфигурациях для Cypress GitHub Action, но давайте вернемся буквально на минутку на шаг назад, чтобы упомянуть некоторые детали в задаче cypress-run
. Параметр runs-on
определяет, какую машину мы хотим использовать для тестов. Действие actions/checkout@v3
может показаться немного странным — зачем выполнять checkout для проекта, над которым мы сейчас работаем? На самом деле причина довольно проста. Есть много вещей, которые можно делать с помощью GitHub Actions, но которые не включают выполнение checkout репозитория. Например, отправка уведомления в Slack при появлении нового кода в удаленной ветке.
Теперь давайте сосредоточимся на том, как можно использовать GitHub Actions для улучшения workflow.
Запускать тест вручную
Вместо того, чтобы запускать тест при каждом push, его можно запускать по требованию. Файл настроек будет выглядеть следующим образом:
name: e2e-tests
on: [worfklow_dispatch]
jobs:
cypress-run:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cypress run
uses: cypress-io/github-action@v5
with:
start: npm start
После того, как вы настроите файл таким образом, можно перейти на GitHub и на вкладке "Actions" запустить рабочий процесс e2e-tests
вручную.
Действия GitHub и Cypress Cloud
Cypress Cloud (ранее Cypress Dashboard) — это сервис для записи результатов тестов в Cypress. Он предлагает вид на тесты «с высоты птичьего полета», что помогает эффективно анализировать и поддерживать тесты. Запись результатов в сервис Cypress Cloud довольно проста. В качестве первого шага необходимо подключить проект к сервису. Это делается прямо в открытом режиме Cypress.
На этом шаге будет сгенерирован уникальный ключ, который будет использоваться для авторизации GitHub Actions для связи с облаком Cypress. Скопируйте этот ключ и добавьте его в среду в своем GitHub Project под именем CYPRESS_RECORD_KEY
.
В качестве последнего шага нужно отредактировать файл workflow:
name: e2e-tests
on: [push]
jobs:
cypress-run:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cypress run
uses: cypress-io/github-action@v5
with:
start: npm start
record: true
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
Это позволит записывать результаты в Cypress Cloud и добавит ключ Cypress в переменную окружения, чтобы программа Cypress могла его использовать.
Запись результатов в Cypress Cloud дает некоторые удивительные возможности. Вы можете просматривать скриншоты и видео из Cypress run, что может помочь отладить тесты, или вы можете посмотреть долгосрочную аналитику и проверить состояние тест-сьюта. Кроме того, есть несколько полезных интеграций. Если вы не хотите постоянно переключаться между Cypress Cloud и GitHub, отправляйте результаты тестирования прямо в GitHub.
После настройки интеграции результаты тестирования будут отправлены прямо в комментарии вашего пул-реквеста и на вашу электронную почту.
Интеграция с GitHub также станет частью проверки пул-реквеста, чтобы можно было предотвратить интеграцию пул-реквеста в основную ветку, если тесты провалятся.
Параллельный запуск тестов
Cypress Cloud позволяет запускать тесты параллельно, и сразу после настройки проекта вы сможете легко разделить тесты на несколько машин. Конфигурационный файл будет выглядеть следующим образом:
name: e2e-tests
on: [push]
jobs:
cypress-run:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
containers: [1, 2, 3]
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Cypress run
uses: cypress-io/github-action@v4
with:
start: npm start
record: true
parallel: true
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
Эта установка запустит три машины и выполнит все steps
параллельно. Флаг parallel: true
обеспечит связь теста с Cypress Cloud и разделит все тесты между машинами. Cypress Cloud также позаботится об автоматической балансировке нагрузки при работе тестов, чтобы выполнение теста занимало как можно меньше времени.
Флаг fail-fast
гарантирует, что GitHub не прервет работу в случае неудачного теста. Если установить это значение в true, вы рискуете оставить тест висеть на Cypress Cloud. Если вы хотите, чтобы тест в случае ошибки останавливался, это можно настроить в настройках проекта в Cypress Cloud. Там даже можно установить количество тестов, при выполнении которых запуск всех тестов будет отменен.
Параллельный запуск без Cypress Cloud
Как раз когда я писал эту статью, Глеб Бахмутов выпустил плагин, который позволяет запускать тесты параллельно без использования сервиса Cypress Cloud. Он разделит тесты на параллельные машины так же, как это сделал бы Cypress Cloud. Конфигурация довольно проста.
name: e2e-tests
on: [push]
jobs:
cypress-run:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
containers: [1, 2, 3]
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cypress run
uses: cypress-io/github-action@v5
with:
start: npm start
env:
SPLIT: ${{ strategy.job-total }}
SPLIT_INDEX: ${{ strategy.job-index }}
Чтобы предоставить GitHub нужную информацию, необходимо установить переменные окружения SPLIT
и SPLIT_INDEX
. Таким образом, каждому процессу будут назначены необходимые спецификации. Решение будет приниматься автоматически, но есть способы настройки, упомянутые в файле README. Это хорошее решение для ситуаций, когда вам не нужен Cypress Cloud или у вас уже настроена собственный дашборд.
В заключение статьи приглашаем всех желающих на открытое занятие, посвященное основам популярных фреймворков для написания тестов на JavaScript — mocha и chai. Мы рассмотрим основные принципы написания тестов и узнаем, как использовать chai для создания автоматизированных тестов на JavaScript. Напишем пару unit и API тестов.
Основные темы этого открытого урока:
- Основные принципы написания тестов на JavaScript
- Изучение фреймворка mocha
- Изучение библиотеки chai
- Unit и API тесты
Записаться на открытое занятие можно на странице курса "JavaScript QA Engineer".
nronnie
Я уточню, чтобы те, кто новенькие не тратили время на эти грабли - ручной запуск по ивенту
workflow_dispatch
становится доступен только когда *.yaml с ним попадает в главную ветку, хотя запускать с ним после этого можно уже для любой ветки на выбор.Да, и еще, совершенно про фильтры не упомянуто, которые при работе со многими ветками (как это и должно быть) крайне нужны, например: