Как уменьшить время выполнения тестов с Jest? - PullRequest
Новая
       40

Как уменьшить время выполнения тестов с Jest?

0 голосов
/ 06 ноября 2019

Я провожу 60 тестов E2E с Jest и Puppeteer на подчиненном EC2 Jenkins. Время испытаний колеблется от 7 до 90 секунд, в среднем за 24 секунды, что означает общее время при последовательной работе ~ 24-25 минут. При запуске jest -w 10 он запускает 10 тестов параллельно, но каждый тест занимает больше времени, а время напоминает jest --runInBand, оба заканчиваются примерно через 24-26 мин.

Я читаю это и связанные с нимиссылки и т.д. изменили машину, на которой я работаю, на r5ad.12xlarge (48 ядер, 384 ГБ!) из-за предположения об ограниченных ресурсах и по-прежнему не влияющих на общее время работы. Больше попыток я сделал:

  • Пробовал с --ci --detectOpenHandles и без него, все равно ничего.
  • NODE_OPTIONS=--max_old_space_size=4096 тоже не изменилось.
  • Ран с по умолчанию, 2, 3, 9, 15 ... working.
  • Проверено использование кучи с помощью node --expose-gc ./node_modules/.bin/jest --runInBand --logHeapUsage и обнаружены некоторые утечки - использование кучи постепенно увеличилось с ~ 100 МБ до 1100 МБ
  • Пробовал работать локально намашина (без ограничений Jenkins на ресурсы, если таковые имеются ...)

У меня вопрос, если я что-то упускаю (флаг, политика агента Jenkins)? Может быть, я должен попробовать другой тестер для целей E2E, потому что jest больше ориентирован на юнит-тестирование?

1 Ответ

0 голосов
/ 07 ноября 2019

После еще нескольких попыток я выяснил основные проблемы:

  1. В Jenkins есть ошибка , когда вы обновляете defaultValue в конвейере, она вступает в силу только последругая сборка. Поэтому удаление --detectOpenHandles сделало мою сборку длинной даже после ее удаления. Кроме того, из-за этого было трудно следить за результатами.
  2. Шут действительно зависит от количества доступных ядер, поэтому я изменил машину на c5.4xlarge с 16 vCPU, и это также имело большое значение. Моя хорошая настройка состояла в том, чтобы установить --maxWorkers=33%, потому что наше веб-приложение также работает на той же машине.

Надеюсь, это кому-нибудь поможет.

...