Возможно, вы задавались вопросами о GitHub Actions. Он кажется сложным, но на самом деле это мощный и простой в освоении инструмент, который может вам помочь. Давайте рассмотрим, как использовать его для запуска Cypress тестов. Давайте сначала посмотрим, чего мы пытаемся достичь. Цель состоит в том, чтобы запустить тесты в Cypress с помощью GitHub Actions. Для этого нужно взглянуть на репозиторий, с которым мы работаем. В качестве примера я буду использовать свой проект trelloapp. Всякий раз, когда я тестирую приложение локально, мне нужно сделать две вещи: запустить приложение на localhost запустить тесты на localhost. Для того, чтобы сделать это на сервере GitHub Action, сначала нужно запустить проект и установить все необходимое. Также нужно определить, в каких случаях мы хотим запускать тесты (например, запускать их по требованию или каждый раз, когда появляется новый код). Так постепенно формируется план того, как будут выглядеть GitHub Action. В GitHub Actions эти планы называются "workflows". Теперь давайте создадим файл workflow. Он будет располагаться в папке .github/workflows: Именно здесь GitHub Actions будет искать workflow файлы. Это файлы формата YAML, их можно рассматривать как набор правил, описывающих, что должен делать GitHub Actions. Они, как правило, довольно линейны, хотя в них можно написать условную логику. Давайте разберем, что происходит в этом файле. В первой строке мы даем действию имя. Оно может быть любым, но лучше, чтобы было описательным. Во второй строке определяем событие, по которому должен выполняться данный сценарий. Существует множество различных событий, таких как 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, его можно запускать по требованию. Файл настроек будет выглядеть следующим образом: После того, как вы настроите файл таким образом, можно перейти на GitHub и на вкладке "Actions" запустить рабочий процесс e2e-tests вручную. Cypress Cloud (ранее Cypress Dashboard) — это сервис для записи результатов тестов в Cypress. Он предлагает вид на тесты «с высоты птичьего полета», что помогает эффективно анализировать и поддерживать тесты. Запись результатов в сервис Cypress Cloud довольно проста. В качестве первого шага необходимо подключить проект к сервису. Это делается прямо в открытом режиме Cypress. На этом шаге будет сгенерирован уникальный ключ, который будет использоваться для авторизации GitHub Actions для связи с облаком Cypress. Скопируйте этот ключ и добавьте его в среду в своем GitHub Project под именем CYPRESS_RECORD_KEY. В качестве последнего шага нужно отредактировать файл workflow: Это позволит записывать результаты в Cypress Cloud и добавит ключ Cypress в переменную окружения, чтобы программа Cypress могла его использовать. Запись результатов в Cypress Cloud дает некоторые удивительные возможности. Вы можете просматривать скриншоты и видео из Cypress run, что может помочь отладить тесты, или вы можете посмотреть долгосрочную аналитику и проверить состояние тест-сьюта. Кроме того, есть несколько полезных интеграций. Если вы не хотите постоянно переключаться между Cypress Cloud и GitHub, отправляйте результаты тестирования прямо в GitHub. После настройки интеграции результаты тестирования будут отправлены прямо в комментарии вашего пул-реквеста и на вашу электронную почту. Интеграция с GitHub также станет частью проверки пул-реквеста, чтобы можно было предотвратить интеграцию пул-реквеста в основную ветку, если тесты провалятся. Cypress Cloud позволяет запускать тесты параллельно, и сразу после настройки проекта вы сможете легко разделить тесты на несколько машин. Конфигурационный файл будет выглядеть следующим образом: Эта установка запустит три машины и выполнит все steps параллельно. Флаг parallel: true обеспечит связь теста с Cypress Cloud и разделит все тесты между машинами. Cypress Cloud также позаботится об автоматической балансировке нагрузки при работе тестов, чтобы выполнение теста занимало как можно меньше времени. Флаг fail-fast гарантирует, что GitHub не прервет работу в случае неудачного теста. Если установить это значение в true, вы рискуете оставить тест висеть на Cypress Cloud. Если вы хотите, чтобы тест в случае ошибки останавливался, это можно настроить в настройках проекта в Cypress Cloud. Там даже можно установить количество тестов, при выполнении которых запуск всех тестов будет отменен. Как раз когда я писал эту статью, Глеб Бахмутов выпустил плагин, который позволяет запускать тесты параллельно без использования сервиса Cypress Cloud. Он разделит тесты на параллельные машины так же, как это сделал бы Cypress Cloud. Конфигурация довольно проста. Чтобы предоставить GitHub нужную информацию, необходимо установить переменные окружения SPLIT и SPLIT_INDEX. Таким образом, каждому процессу будут назначены необходимые спецификации. Решение будет приниматься автоматически, но есть способы настройки, упомянутые в файле README. Это хорошее решение для ситуаций, когда вам не нужен Cypress Cloud или у вас уже настроена собственный дашборд. В заключение статьи приглашаем всех желающих на открытое занятие, посвященное основам популярных фреймворков для написания тестов на JavaScript — mocha и chai. Мы рассмотрим основные принципы написания тестов и узнаем, как использовать chai для создания автоматизированных тестов на JavaScript. Напишем пару unit и API тестов.  Основные темы этого открытого урока:- Основные принципы написания тестов на JavaScript- Изучение фреймворка mocha- Изучение библиотеки chai- Unit и API тесты Записаться на открытое занятие можно на странице курса "JavaScript QA Engineer".  Переводчик, редактор