Скорочення часу виконання Jest локально та в CI: Workers, кешування та область видимості

Повільний набір тестів поступово змінює спосіб роботи команди: люди запускають тести рідше, надсилають код у CI для перевірки та чекають найдовше саме тоді, коли це найменш доцільно — під час виправлення проблем у продакшені. Ці витрати зростають, коли асистенти з кодування на основі ШІ швидко створюють зміни, а набір тестів залишається основним засобом безпеки. Jest постачається з багатьма опціями налаштувань та розумними значеннями за замовчуванням, тож базова робота зазвичай є прийнятною, але кілька коректив можуть значно скоротити час виконання як на ноутбуці, так і у CI. Жоден з цих методів не є складним; разом вони утворюють корисний перелік кроків.

Вимірюйте перед налаштуванням

Кожна зміна має свою вартість чи компроміс, тому почніть з цифр. Виміряйте час повного виконання без кешу (jest --no-cache) щоб отримати базові показники, потім внесіть одну зміну за раз та знову виміряйте.

Налаштовуйте паралелізм відповідно до потужності пристрою

Jest за замовчуванням виконує тестові файли паралельно у робочих процесах, що зазвичай є хорошим рішенням, але не завжди оптимальним. Це контролюється двома флагами:

• --runInBand виконує всі тести послідовно у поточному процесі без використання робочих процесів. Це може бути швидшим для проєктів серверної частини, у яких тести спільно використовують дорогий ресурс, або на системах CI з дуже малою кількістю ядер, де створення робочих процесів коштує більше, ніж економить.
• --maxWorkers визначає кількість робочих процесів, які створює Jest. Він приймає число або відсоток від доступних ядер; 50% є розумною відправною точкою, яка залишає місце для решти обладнання.

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

Зберігайте глобальну налаштування простими

Файл глобальних налаштувань зручний у великому кодовому базі: достатньо один раз зареєструвати моки, поліфіли та інструменти для тестування, і кожен тест їх отримає. Проблема полягає у тому, що кожен файл тестів оплачує всю цю інфраструктуру, включаючи ті файли, яким вона не потрібна. Важкі імпорти, налаштування бази даних чи великі реєстри моків у setupFilesAfterEnv можуть перетворити інакше мілісекундно швидкі тести на повільні.

Перемістіть витратні налаштування ближче до тестів, яким вони потрібні: допоміжний модуль, імпортований явно, функція beforeAll у відповідному файлі чи окремий проект Jest із власною налаштуванням для тестів інтеграції.

Повторне використання кешу

Другі запуски зазвичай відбуваються швидше, ніж перші, оскільки Jest кешує трансформовані файли та іншу метадані. Це найбільше помітно у режимі спостереження, але CI також отримує переваги, якщо кеш зберігається між завданнями. Вкажіть cacheDirectory на стабільний шлях та збережіть його за допомогою функції кешування вашої системи CI, використовуючи як ключ файл блокування та конфігурацію Jest, щоб кожна пайплайн-сесія починалась не з нуля.

Використовуйте режим спостереження локально

Для роботи в локальних умовах jest --watch — це найкращий механізм зворотного зв’язку, який пропонує Jest. Він перезапускає лише ті тести, які стосуються змінених файлів, а його інтерактивне запитування дозволяє фільтрувати за назвою файлу чи шаблоном назви тесту. Цей режим не призначений для CI: пайплайну потрібен один запуск, який завершується кодом статусу, тому залишайте режим спостереження на машинах розробників.

Увімкніть isolatedModules для TypeScript

Коли тести TypeScript виконуються за допомогою ts-jest, повна перевірка типів кожного файлу створює значний навантаження. Увімкнення параметра isolatedModules змушує трансформатор компілювати кожен файл окремо, без інформації про типи з решти програми. Команди, які працюють над проектами Angular, повідомляють про чітке прискорення роботи завдяки цьому, і ви втрачаєте дуже мало у рівні безпеки, якщо tsc --noEmit або ваш редактор все ще перевіряють кодову базу на типи. Місце розташування цього параметра залежить від версії ts-jest, тому перевірте його поточну документацію.

Тестуйте лише те, що може змінитися внаслідок зміни

Немає жодних причин запускати весь набір тестів через зміни, які стосуються лише одного пакету. Сам Jest дозволяє звузити спектр тестів за допомогою параметрів --onlyChanged або --changedSince=<branch>, які використовують систему контролю версій для пошуку відповідних тестів. У монорепозиторії системи збірки на кшталт Nx йдуть ще далі, аналізуючи структуру проекту та запускаючи тести лише для тих проектів, які постраждали від поточних змін.

Зберігайте принаймні один повний запуск тестів, наприклад на головній гілці чи щовечора, щоб виявити все те, що може пропустити аналіз залежностей.

Розгляньте Vitest

Vitest у великій мірі сумісний з API Jest, активно підтримується та працює з поширеними фреймворками JavaScript, включаючи Nuxt. Для проектів, вже створених на Vite, це часто є більш природним вибором, і багато команд тепер обирають його першим для нових проектів. Більшість вищезазначених порад — щодо вимірювань, обмежень працівників, мінімалістичної налаштування та запуску лише відповідних тестів — так само стосуються Vitest. Якщо ви розглядаєте можливість повністю відмовитися від стороннього засобу тестування, перегляньте заміну Jest на вбудований засіб тестування Node.

Коли налаштування програмного забезпечення більше не допомагає

Зрештою жодна зміна конфігурації не допоможе так, як швидше обладнання. Новий ноутбук або більший самостійно розгорнутий засіб CI може бути найдешевшим способом покращення, коли сама сујта тестів вже у гарному стані.

Основні висновки

• Встановіть початковий рівень без кешування та змінюйте щось по одному елементу за раз.
• Налаштуйте значення --maxWorkers або --runInBand відповідно до реальних можливостей кожного середовища.
• Перенесіть ресурсомісткі процедури налаштування з глобальних функцій у тести, які їх потребують.
• Зберігайте кеш Jest між запусками CI; режим спостереження використовуйте лише локально.
• Нехай параметр isolatedModules пропускає перевірку типів для окремих файлів, тоді як окремий крок tsc забезпечує точність типів.
• На гілках з функціями виконуйте лише відповідні тести, а на основній гілці — повний набір тестів.