Автоматизированное тестирование с помощью GitHub Actions

В этой статье мы хотим изучить, как автоматически тестировать наш код с помощью GitHub Actions при отправке обновлений в наш удаленный репозиторий.

Мы рассмотрим минимальный пример, чтобы узнать об основных строительных блоках GitHub Actions и узнать, как их настроить.

Предпосылки

Предполагаются некоторые базовые знания в области программирования, а также понимание концепции непрерывной интеграции и непрерывной доставки (CI/ CD).

Примеры кода написаны на JavaScript, но должны быть понятны без знания JS.

Концепции и идеи можно перенести на другие языки программирования и платформы.

Что такое действия GitHub?

GitHub Actions — это платформа CI/CD, которая автоматизирует сборку, тестирование и развертывание кода.

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

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

GitHub Actions делает еще один шаг вперед и позволяет создавать рабочие процессы, выходящие за рамки кода. Например, можно создать рабочий процесс, который автоматически добавляет соответствующую метку к задачам, которые создаются в репозитории.

Пример проекта

Чтобы поиграть с действиями GitHub, мы рассмотрим очень простой пример в Node.js.

Мы напишем базовую функцию, которая складывает два числа, и реализуем модульный тест для этой функции с помощью Jest. Затем мы создадим рабочий процесс GitHub Actions для автоматического запуска набора тестов при каждом PR и каждой отправке в основную ветку.

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

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

Тем не менее, просто прочитав статью, вы получите хороший обзор и общее представление о GitHub Actions.

Наша установка довольно проста: проект Node.js с Jest в качестве зависимости от разработчиков для модульного тестирования.

Мы начнем с создания файла app.js с простой функцией sum:

function sum(a, b) {
  return a + b;
}
module.exports = { sum };

Далее мы создадим файл app.test.js с одним тестом для функции sum:

const sum = require("./app").sum;

test("add two numbers", () => {
  expect(sum(3, 5)).toBe(8);
});

Наконец, давайте добавим скрипт test в наш package.json:

{
    ...
  "scripts": {
    ...
    "test": "jest"
  },
  ...
}

Мы можем запустить наш набор тестов из командной строки с помощью npm test.

Хотя большинство разработчиков, вероятно, запускают набор тестов, прежде чем вносить какие-либо изменения в базу кода, об этом шаге можно легко забыть. Кроме того, запуск тестов в крупных проектах может занять довольно много времени, и у нас может возникнуть соблазн пропустить тесты, когда нужно срочно что-то протолкнуть.

Поэтому мы хотим убедиться, что тесты запускаются автоматически при каждом изменении кодовой базы.

Давайте посмотрим, как GitHub Actions может помочь в этом.

Рабочий процесс автоматического тестирования

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

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

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

Построение рабочего процесса

Чтобы добавить рабочие процессы в репозиторий GitHub, мы создаем папку верхнего уровня .github с подпапкой workflows. Там мы добавляем файл YAML для каждого рабочего процесса, который мы хотим иметь. В нашем случае это будет только один файл test.yml:

name: test
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: "16"
      - run: npm ci
      - run: npm test

Давайте рассмотрим составные части этого файла более подробно.

name: test

👉 Довольно просто: название нашего рабочего процесса.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

👉 Блок on описывает, какие события запускают рабочий процесс. В этом случае мы хотим, чтобы наш рабочий процесс test запускался при любых отправках в ветку main и при создании или обновлении запроса на включение в main. .

jobs:
  test:
    runs-on: ubuntu-latest

👉 В блоке jobs перечислены все jobs, из которых состоит рабочий процесс. Задание выполняется на раннере и состоит из одного или нескольких шагов. В нашем случае у нас есть только одно задание с именем test, которое выполняется в среде запуска Ubuntu.

GitHub предоставляет набор бегунов на выбор, например. Ubuntu, macOS и Windows Server.

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

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

steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-node@v3
    with:
      node-version: "16"
  - run: npm ci
  - run: npm test

👉 Блок steps точно описывает, что делает наше задание test.

На каждом шаге может выполняться многоразовое действие или собственный скрипт.

На рынке GitHub представлены многочисленные действия для различных сред и вариантов использования.

Чтобы не изобретать велосипед, мы используем два из этих действий в наших первых двух шагах, чтобы проверить код и установить Node v16 на нашу программу запуска Ubuntu, которую мы указали в блоке jobs.

На следующих двух шагах мы запускаем две команды для установки зависимостей npm и выполняем команду test из нашего package.json. Это возможно только потому, что мы настроили среду на шагах 1 и 2 с предварительно созданными действиями.

Эти шаги можно легко адаптировать для других сред и языков программирования.

Вот и все, мы закончили построение нашего рабочего процесса. 🥳

Добавление рабочего процесса в репозиторий

Чтобы активировать только что созданный рабочий процесс, все, что нам нужно сделать, это отправить наш код с новой папкой .github/workflows в наш репозиторий GitHub. Затем рабочий процесс будет автоматически запускаться для указанных событий.

Мы также можем перейти к настройкам репозитория и настроить правила защиты ветки для ветки main, чтобы пулл-реквесты в main могли объединяться только тогда, когда test< /code> рабочий процесс выполняется успешно.

Если теперь мы создадим новый PR в main, мы увидим, что GitHub автоматически запускает наш рабочий процесс test и что слияние невозможно до прохождения проверок.

Вот PR, где тесты пройдены и слияние разрешено.

Чтобы увидеть пример сбойного конвейера, посмотрите этот PR.

(Примечание: вам необходимо войти в учетную запись GitHub, чтобы проверить эти PR.)

Дальнейшие шаги

Мы увидели, как настроить автоматическое тестирование всего несколькими строками кода с помощью GitHub Actions, довольно круто. 😎

Конечно, наш пример был очень простым, и мы едва коснулись возможностей GitHub Actions.

Поэтому вот несколько советов и ресурсов для более глубокого изучения:

• просмотреть документацию
• расширить наш примерный проект несколькими рабочими процессами, например. для линтинга и форматирования кода
• добавьте действия GitHub в более сложные проекты

Спасибо за чтение и получайте удовольствие от создания вещей! 🛠️