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

В этой статье продолжим тему ускорения работы тестов Cypress за счет выполнения тестов в несколько потоков. В прошлый раз мы уже рассмотрели ряд инструментов. Тесты уже запускались параллельно, но делалось это вручную. Для Cypress Cloud и Sorry Cypress мы использовали для этого несколько экземпляров терминала, а cypress-parallel сам создавал процессы. Но лучше, когда наши тесты выполняются в рамках CI-CD. Будем двигаться от простого к сложному и начнем с инструмента, с которым проще всего сделать настройку для Gitlab.

Содержание

• Когда параллельный запуск поможет
• Используем cypress-parallel в gitlab
• Используем стратегию GitLab parallel и cypress-split
• Итоги

Когда параллельный запуск поможет

Стоит уточнить, что параллельный запуск помогает не всегда. Все зависит от того сколько ядер процессора выделено для Gitlab runner. Чем больше ядер, тем больше будет выгода. Если ядро всего одно (что обычно в штатном shared runner у Gitlab), то выгоды не будет никакой. Если у вас своя машина под runner с несколькими CPU, то смысл в параллельном запуске будет.

Чтобы понять сколько ядер в вашем runner можно использовать такую команду (script) в job для CI-CD:

echo "CPUs available:" $(nproc)

Используем cypress-parallel в gitlab

В случае с Cypress Cloud и, особенно, Sorry Cypress шаги по настройке не так очевидны. Особенно во втором случае. Нам необходимо где-то запустить все сервисы, а затем думать, как запустить все экземпляры (процессы) cypress.

В случае же с cypress-parallel у нас просто будет запуск команды в scripts для job. Эта инструкция запустит код пакета, который сам осуществит разделения тестов на указанное число потоков.

Для удобства можно добавить команды в наш frontend/package.json:

  "scripts": {
//...
    "cy:run": "cypress run",
    "cy:parallel" : "cypress-parallel -s cy:run -t 4 -d 'cypress/e2e/**/*.cy.{ts,js}'"
  },

Здесь -t 4 – это запуск 4 потоков. Их должно быть не больше чем ядер процессора.

Затем в .gitlab-ci.yml у нас будет вызвана команда npm run cy:parallel:

    script:
# ...
        - echo "CPUs available:" $(nproc)
        - npm run cy:parallel

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

Используем стратегию GitLab parallel и cypress-split

Есть другой способ. Указать для job параметр parallel: 4 и использовать script, который разделяет ваши тесты на указанное число порций. Чтобы не писать скрипт самостоятельно, можно взять готовый пакет cypress-split.

Нам нужно выполнить следующие шаги:

• Добавить пакет npm i -D cypress-split
• Использовать в job .gitlab-ci.yml инструкцию parallel: 4 (здесь также величина не более числа ядер)
• В script для job добавить команду npx cypress run --env split=true

Gitlab CI-CD вместе с данным скриптом понимает как запустить тесты в указанное число потоков.

Запуск вручную, как в предыдущей статье, для cypress-split тоже возможен:

npx cypress run --env split=3,splitIndex=1

В данном случае используются следующие параметры:

• split – число групп тестов, на которое будет разбиты все тесты
• splitIndex – номер группы, которую нужно запустить (начиная с 0)

Считается, что один и тот же набор тестов будет разбит на группы одинаковым образом (при неизменном числе групп). Поэтому, запуская в соседних терминалах скрипт с разным значением `splitIndex`, мы запустим разные тесты. Наложения или пропуска тестов не будет, когда мы запустим все группы разом.

В Gitlab pipeline данный job будет виден в 4 экземплярах ( по значению указанному в параметре parallel ). Логи и артефакты можно смотреть по каждому из них.

В тоже время, с cypress-parallel такой картины не будет. Там будет сводная таблица в логе, как было продемонстрировано в предыдущей статье.

Итоги

Если нам не нужна удобная панель для работы с результатами запуска тестов и историей (как в Cypress Cloud), то можно настроить Gitlab CI-CD с использованием cypress-parallel или cypress-split. Таким образом, мы добьемся запуска тестов в параллельных процессах не тратя много времени и денег на это. Однако, чтобы данные меры помогли, нам нужен Gitlab runner с несколькими ядрами.

Будет интересно узнать из комментариев кто из вас какие инструменты использует для для этих целей.