Cypress test runner - отличная альтернатива Selenium в области сквозного тестирования. Когда дело доходит до тестов E2E, они, как правило, со временем разрастаются, и их выполнение происходит медленно и становится пустой тратой времени или просто перерывом на кофе для разработчиков. ;)

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

Проблема с разделением тестов на параллельных машинах

Если вы хотите запустить свой набор тестов на нескольких узлах CI одновременно, вам необходимо решить, какой тестовый файл будет направлен на определенные узлы CI.

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

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

Даже провайдер CI может вызвать дополнительную проблему. Иногда время загрузки ваших параллельных узлов CI может отличаться. Один узел CI начинает работу позже других или, возможно, он застрял в очереди из-за запуска какой-либо другой сборки CI в учетной записи вашей организации.

Некоторые поставщики CI позволяют использовать большое количество параллельных узлов CI для ускорения ваших тестов за счет использования вашей собственной серверной инфраструктуры, такой как AWS, с очень дешевыми вытесняемыми ресурсами - спотовыми инстансами Amazon EC2 (в случае Google у вас есть виртуальные машины с вытесняемым облаком Google ). Обратной стороной этого является то, что AWS или Google хотят забрать ваш сервер во время выполнения ваших тестов. Внезапно вы теряете один из ваших параллельных узлов CI, и вам нужно повторить попытку, и он становится вашим узким местом.

Как динамически распределять тесты между параллельными узлами CI для экономии времени?

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

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

Knapsack Pro API также может запоминать тесты, назначенные каждому параллельному узлу CI. Если вы потеряли один из параллельных узлов CI во время выполнения из-за того, что AWS или Google вытеснили вашу машину, вы можете просто повторить попытку убитого узла CI и запустить только те тесты, которые были потеряны. Другие параллельные узлы CI потребуют больше тестов из очереди, прежде чем вы снова попытаетесь отключить узел CI, поэтому вы не будете тратить дополнительное время на выполнение тестов, которые не были потеряны.

Запускайте Cypress-тесты в режиме очереди Knapsack Pro

Чтобы быстрее запускать тесты, вы можете добавить в свой проект пакет @ knapsack-pro / cypress. Он работает со многими поставщиками CI из коробки. Здесь вы можете найти подробный ридми.

По сути, мы запускаем одну команду на всех параллельных узлах CI, а Knapsack Pro позаботится о быстром запуске ваших тестов.

$(npm bin)/knapsack-pro-cypress

В видео ниже я покажу вам пример проекта Cypress и то, как запустить его на параллельных узлах CI.

Надеюсь, что это поможет вам. Я хотел бы услышать от вас отзывы и обменяться идеями о том, как можно было бы проводить наши тесты еще быстрее!

Первоначально опубликовано на docs.knapsackpro.com.