Распараллеливание Тестов Или Одна Голова — Хорошо, А Две — Лучше

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

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

Hudson начнет сообщать о неработающих сборках, и тогда все заработает эффект разбитого окна и сломанная сборка станет нормой.

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

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

В одном из наших проектов, в котором по записям Редмайн Наша команда вложила около 400 часов работы; ситуация с тестами до распараллеливания выглядела так (пару дней назад):

151 scenarios (151 passed) 3997 steps (3997 passed) 17m49.257s

18 минут!!! За это время разработчик может приготовить кофе, выкурить сигарету, сходить в туалет, ущипнуть симпатичную коллегу за задницу и успеть посмотреть последние 3 минуты «матрицы» на экране.

Если вы потребуете от него выполнения полного прогона перед каждым коммитом, то все, что он будет делать, — это смотреть на «матрицу», зажимать задницы и пить кофе.

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

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

параллельные_тесты .

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

Гем Parallel_tests по сравнению со своими аналогами ( гидра , тестовый тур ) выделяется тем, что позволяет распараллелить наши любимые интеграционные тесты на огурце+capybara+selenium-webdriver, которые из-за обширной ajaxификации нашего приложения не могут быть выполнены без реального браузера, иными словами, запуститься через гем Капибара Fire Fox. В этом случае фактически запускается несколько копий Firefox, по которым более-менее равномерно распределяется нагрузка.

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

И, что играет немаловажную роль, адаптировать приложение для использования этого драгоценного камня очень просто.

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

Сам гем при запуске устанавливает переменную окружения TEST_ENV_NUMBER, поэтому в файле data.yml ее можно прописать в тестовом разделе.



test: database: xxx_test<%= ENV['TEST_ENV_NUMBER'] %>

Естественно, перед запуском базы необходимо создать вручную или через

rake parallel:create

Во-вторых, необходимо обеспечить синхронизацию схем БД при проведении дополнительных миграций или повторном запуске старых:

rake parallel:prepare

В-третьих, нужно проводить пробежку по-другому.



rake parallel:features

Это для запуска функций огурца.

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

Да, гем, конечно, нужно прописать в Gemfile и установить

bundle install

В итоге вот результаты последней сборки Hudson на восьмиядерном процессоре Selectelov Xeoncheg.

Results: 17 scenarios (17 passed) 347 steps (347 passed) 31 scenarios (31 passed) 780 steps (780 passed) 8 scenarios (8 passed) 149 steps (149 passed) 26 scenarios (26 passed) 1363 steps (1363 passed) 26 scenarios (26 passed) 463 steps (463 passed) 17 scenarios (17 passed) 331 steps (331 passed) 6 scenarios (6 passed) 88 steps (88 passed) 19 scenarios (19 passed) 410 steps (410 passed) Took 338.989782947 seconds Finished: SUCCESS

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

Но 150 против 151 не намного меньше.

А вот по времени - 5 с половиной минут против почти 18. Сюда же учтено около 60-70 секунд постоянных затрат на свежее извлечение из репозитория, ремиграцию баз и запуск фаерфокса.

Результат налицо, и в результате всего за сутки сборка в Хадсоне стабилизировалась — последние 5 коммитов успешно отработали полный набор тестов, чего и всем желаю.

UPD: Если в параллельном режиме не определяются Step_definitions, решение нашел Хабраман.

Ольха .

Затем вам нужно запустить тесты следующим образом:

parallel:features[2,'','--require features']

Теги: #огурец #интеграционное тестирование #capybara #параллельные вычисления #ruby onrails #тестирование ИТ-систем

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.