Jest: Jest в 3 раза медленнее на всех машинах с Windows (Windows 10 и ниже)

Связанный: # 6783

Медленно запускается, или в режиме часов тоже? Если только во время запуска, вы можете попробовать установить watchman , это должно помочь (https://facebook.github.io/watchman/docs/install.html)

Когда он проходит тесты, с этого момента он кажется прекрасным (РЕДАКТИРОВАТЬ: на самом деле он медленнее и при запуске тестов. Он проходит один за другим со скоростью 0,5 секунды, в то время как норма кажется 0,05
секунд на тест)
Однако он медленно запускается и / или запускает шутливые тесты (задержка около 4-6 секунд, в 4-6 раз медленнее, чем у компьютеров Mac).

Я попробую сторожа и вернусь к тебе

Если бы вы могли профилировать, например, ndb стартап, и выяснить, что тормозит, это тоже было бы большим подспорьем 🙂

Задержка все еще медленная, даже если установлен сторож.
Я провел тест профилирования с ndb, запустив "jest --verbose", вот результаты:

Скриншот первых 1,7 секунды:

Снимок экрана с 1,8 секунды до 2,7 секунды

Файл .json и файл .heapsnapshot, сохраненные на вкладке профиля в ndb после записи:

profiling.zip

@pfftdammitchris, в каком [точном] случае вы заметили медленное движение?
(один файл или несколько файлов)? (режим часов или нет)? вы можете предоставить пример.
для проблемы с режимом просмотра одного файла => пожалуйста, прочтите мой последний комментарий в: # 6783

Это медленно как для одного, так и для нескольких файлов, с режимом просмотра или без него. Практически каждый раз, когда он запускает какой-либо тест, возникает задержка в 3+ секунды при инициализации тестов, и он медленно запускает тесты один за другим на 0,3, 0,4 или 0,5 секунды каждый, в то время как другие участники тестирования, такие как mocha / chai, обычно просто запускают каждый, как будто он кажется 0,05 секунды каждый.

Я использую jest в codeandbox, и они, кажется, запускают jest мгновенно при инициализации / запуске тестов, я наблюдал, как мои коллеги запускали jest на своих машинах Mac, и они запускали его мгновенно, как обычно. Насколько я знаю, это просто машины с Windows. Я использую машину с Windows на работе, и у jest есть проблема с медленной скоростью, и я также использую машину с Windows дома, и здесь проблема сохраняется.

Я использовал --runInBand, но, судя по ощущениям, это немного замедлило модульные тесты еще на дополнительные 0,2 секунды каждый.

Разъяснение

Я использовал --runInBand, но, судя по ощущениям, это немного замедлило модульные тесты еще на дополнительные 0,2 секунды каждый.

=> вы пробовали с v24? с v23 на v24, вы увидите хорошее улучшение ТОЛЬКО для этого сценария:
_на rerun с watch и только если вы запускаете один файл (не при первом запуске) _
-> снижение с 2/3 до 0,4 / 0,5 с.
но по сравнению с Mac я никогда не пробовал ... так что, может быть, все еще плохо ... даже с текущим улучшением

@SimenB

1. Я считаю https://github.com/facebook/jest/issues/7110 регрессией скорости Jest [v22 vs v23] в Windows для ВСЕХ проблемных сценариев.
   где # 6783 - один из них

2. Я могу рассматривать эту проблему как: проблема скорости для шутки [Mac против Windows] для ВСЕХ проблемных сценариев.

Всем привет !
Накопил медлительность jest 24 и windows 10 (800 на 400 тестов!). Я нашел более быстрый способ ускорить все это - использовать wsl вместо powershell или cmd. Сейчас мои тесты занимают "всего" 189 секунд.

У нас есть набор из 144 файлов тестов с 1302 тестами, выполнение которых занимает 1 минуту 43 секунды на машине Windows 10, сборка 15063, Core i7 с 16 ГБ и 28 секунд на Mac OS Mojave с 32 ГБ. Наша команда разработчиков поровну разделена между Windows и Mac, и цифры очень повторяемы.

Вот простой тест -

it("works", () => {
  expect(1).toEqual(1);
});

Я помещаю его вcodeandbox, и он запускается практически мгновенно - https://codesandbox.io/s/4q8l0q52lw

на моей машине с Windows, хотя это занимает 4-5 секунд -

ПРОЙДИТЕ src / index.test.js
v работает (62 мс)

Наборы тестов: 1 пройден, всего 1
Тесты: 1 сдан, всего 1
Снимки: всего 0
Время: 4.158 с
Прогнал все наборы тестов.

Сам тест занял 62 мс, но остальная часть тестовой системы заняла 4 секунды. Повторный запуск теста нажатием клавиши Enter занимает такое же время.

Мои настройки -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

Я попробовал это с WSL Ubuntu и получил те же результаты (4-5 секунд) - эти настройки -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

Я только начинаю работать с Jest, поэтому у меня есть довольно простые тесты, на выполнение которых может потребоваться 15-20 секунд. Я бы хотел, чтобы они работали быстро - иначе я теряю ход мыслей!

@bburns прочитал выше проблему

@kensherman
Можете ли вы попробовать микроматч 4 в ваших разрешениях пряжи. посмотреть, не лучше ли в windows пожалуйста?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

Я на новеньком MacBook Pro. Поскольку у меня есть студенты, работающие как на MacOS, так и на Windows 10, я решил добавить на свой диск еще два раздела; один для Windows 10 и один для общего хранилища с использованием Tuxera NTFS.

Я столкнулся с этой проблемой скорости сегодня, когда готовил урок JavaScript, который включает модульные тесты. На самом деле я запускаю Jest из MacOS, но код и тесты находятся в общем разделе NTFS. Даже если все комплекты помечены как describe.skip , выполнение Jest занимает более 10 секунд как в режиме одиночного запуска, так и в режиме просмотра.

8 апартаментов
42 теста

Я поменял местами jest на mocha и chai и пробежки вернулись к режиму с одинарным просмотром в 1 секунду и 10 мсек.

Я поменял местами шутку на мокко и чай, и пробежки вернулись к режиму одинарного просмотра в 1 секунду и просмотра в 10 миллисекунд.

По сути, вы не читали мой последний пост. Вы хотели продвигать mocha/chai ... мы все об этом знаем ... Мы пытаемся исправить регресс шутки. Либо вы поможете сделать это [из моего сообщения] ...can you try with micromatch 4... либо уберите эти бесполезные комментарии из обсуждения. Извините за откровенность, но в какой-то момент нет другого способа сказать это.

@nasreddineskandrani Я пробую [email protected], но я все еще вижу чрезвычайно медленное выполнение при работе в режиме просмотра, любая помощь будет очень признательна.

@pachumon исправление отсутствует в 24.8.0, насколько я понял

вам нужно установить одну зависимость jest для конкретной версии, чтобы удалить проблему с производительностью (теоретически) исправление будет по умолчанию присутствовать в jest 25 => прочтите здесь, чтобы узнать, как разработчик узнает об этом https://github.com/ facebook / jest / issues / 7963 # issuecomment -483985345

чтобы установить зависимость (микроматч) к версии, в которой было выполнено исправление => вы можете проверить здесь, я сделал пример в небольшом проекте
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Добавьте в свой package.json : (необходимо использовать yarn не npm )

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

Надеюсь это поможет! и ждем обратной связи

Время выполнения моего теста также увеличилось с ~ 2,5 минут на 23.6.0 до ~ 15 минут на 24.7.1 и 24.8.0. Наш CI-сервер работает под управлением Windows, и после этого обновления время сборки также увеличилось. Я пробовал переопределение разрешения зависимости микроматчей, как упомянуто выше @nasreddineskandrani, безрезультатно. Пожалуйста, дайте мне знать, если я могу что-нибудь сделать, чтобы помочь в диагностике.

@TomMahle, это супер плохая новость :( (регресс, о котором мы говорим на вершине, уже был в 23.6)
Прямо сейчас простой «образец» проекта действительно показал хорошую производительность. после обновления микроматч.
Итак, нам нужен настоящий проблемный проект для отладки, ваш проект частный? или паблик?

Спасибо за предложение о micromatch @nasreddineskandrani , но, как и @TomMahle выше, ^4.0.0 , похоже, не улучшила производительность для меня. 😢

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

У меня есть возможность запускать jest либо в моей родной системе Windows, либо в контейнере докеров с основным каталогом приложения, установленным из моей файловой системы Windows. Работа в режиме без часов, похоже, имеет почти идентичное поведение в обеих системах, что, возможно, предполагает, как подразумевает @thebearingedge , что основная проблема как-то связана с файловой системой NTFS, поскольку мой контейнер докеров в конечном итоге запускает все, кроме файловой системы в виртуальная машина linux.

Однако в режиме просмотра все немного иначе: собственные окна всегда работают медленно, как и ожидалось, но контейнер докеров медленно запускает тесты только при первом запуске . Как только я приказываю ему запустить любой набор тестов во второй раз (например, нажав p и введя шаблон), он запускает тесты менее чем за одну секунду (выполнение того же самого в собственных окнах занимает 3-4 секунды). Единственным недостатком использования докера является то, что события изменения файла, похоже, не распространяются с моего тома Windows на докер, поэтому мне приходится вручную нажимать Enter, чтобы повторно запустить тест, а не делать это автоматически, но я думаю, что не имеет отношения к рассматриваемой проблеме.

@nasreddineskandrani. К сожалению, мой проект частный. Если есть примеры кода меньшего размера (конфигурация шутки?) Или статистические данные, которые я мог бы предоставить, я с радостью это сделаю. Все тесты кажутся значительно медленнее (только в Windows), поэтому я не думаю, что это связано с конкретными тестами.

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

@TomMahle
Я постараюсь сделать репозиторий на github с описанной вами проблемой.

1. Сколько у вас тестов?
2. вы включаете режим dom для тестов?
3. это реагирует или угловато?
   бонус:
4. вы можете попытаться воспроизвести проблему в репозитории github, чтобы иметь возможность отлаживать?
   вы можете форкнуть мою: https://github.com/nasreddineskandrani/benchmark_jest
   Или же
5. может попробовать мое репо на своей тестовой машине? и увидеть результаты? от 23,6 до 24

Я думал, что разработчикам micromatch было уделено достаточно внимания, так что это, должно быть, уже было устранено. Запуск (а значит, и написание) тестов шутки в Windows на данный момент очень неприятный опыт.

С тех пор я перешел на мокко / чай, но я удивлен, что над этой проблемой все еще работают.

Разъяснение

Я использовал --runInBand, но, судя по ощущениям, это немного замедлило модульные тесты еще на дополнительные 0,2 секунды каждый.

=> вы пробовали с v24? с v23 на v24, вы увидите хорошее улучшение ТОЛЬКО для этого сценария:
_на rerun с watch и только если вы запускаете один файл (не при первом запуске) _
-> снижение с 2/3 до 0,4 / 0,5 с.
но по сравнению с Mac я никогда не пробовал ... так что, может быть, все еще плохо ... даже с текущим улучшением

@SimenB

1. Я считаю # 7110 понижением скорости Jest [v22 vs v23] в Windows для ВСЕХ проблемных сценариев.
   где # 6783 - один из них

2. Я могу рассматривать эту проблему как: проблема скорости для шутки [Mac против Windows] для ВСЕХ проблемных сценариев.

Я пробовал с обеими версиями во время публикации.

Я только что создал новый проект с одним тестом с простыми push-тестами массива, и от начала до завершения потребовалось более 10 секунд. В проекте используется react / typescript, но тестовый файл не является файлом компонента реакции, а является обычным файлом, например .js. Gif ниже для визуальной справки, если это позволяет лучше визуализировать, в чем может быть проблема:

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

Когда я сделал это gif-изображение выше (на этот раз это был второй раз), расчетное время немного сократилось, и второй повтор попытки не был выполнен. Не уверен, что это ожидаемое шутливое поведение.

Вот гифка, на которой я запускаю микроматч 4 с пряжей в отдельном проекте:

При использовании Windows 10 и моих компьютерных спецификаций:
AMD FX (tm) -8320, восьмиядерный процессор, 3,50 ГГц
ОЗУ 16 ГБ
x64
SSD

Позвольте мне поделиться своим профилем здесь.
Технические характеристики:

• Windows 10 Pro
• Узел 10.15.3
• Intel Core i7-4702MQ 2,2 ГГц
• 8 ГБ оперативной памяти
• x64
• SSD

Шаги:

1. npx create-react-app my-app --typescript
2. изменить App.test.tsx
3. запустить npm test

Профиль процессора:

CPU-20190801T141211.zip

Ожидается ли, что 15 секунд будут потрачены только на запросы модулей для одного тривиального компонента React и теста?

Может ли кто-нибудь с большим опытом профилирования ЦП посмотреть?

112 тестов
окна 10
первый запуск 507 секунд
второй пробег 23 секунды
подсистема linux
первый бег 54 секунды
второй пробег 29 секунд

85 тестов
окна 10
первый запуск 44 секунды
второй пробег 15 секунд
подсистема linux
первый запуск 26 секунд
второй пробег 15 секунд

Кепро эти результаты с микроматч 4?

Я предпочитаю прямой чат, чем иметь здесь 1 миллион сообщений, это действительно становится адом, чтобы отслеживать все вопросы, связанные с одной и той же темой.
Вы можете присоединиться здесь. https://gitter.im/wearefrontend/jest-slow-windows
Я сейчас на нем ...

Gitter заблокирован через VPN моей компании - если вы, милые люди, могли бы публиковать здесь какие-либо важные обновления, это было бы замечательно <3

вы все еще можете подключиться дома, чтобы сделать что-нибудь с открытым исходным кодом: P и проверить его
ps игра в доту требует больше времени для очереди, теперь вы можете проверить gitter в это время;)
вот где он сейчас: nodejs / node # 28946

@nasreddineskandrani Ты меня

Похоже, проблема переместилась в область node / C ++, которая немного (чрезвычайно) находится за пределами моей зоны комфорта, но я немного покопаюсь!

Привет, есть новости по этому поводу?

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

В моем проекте на выполнение всех тестов ушло 21,803 секунды.
Теперь с --runInBand требуется всего 7,412 с.

--runInBand для меня просто сделать его еще медленнее. 1200тестов. Без runinBand 70/50 секунд. С --runInBand его 90 секунд в лучшем случае на втором запуске
На Linux это вроде в 5-8 раз быстрее

Тогда попробуйте --maxWorkers = 4.

@ cino893 , а не решение :) попробуйте найти исправление, а не обходной путь

Есть новости по этому поводу? Я сложил версию 21 из-за этой ошибки. v22 медленнее, а v23 еще медленнее.
Вам не кажется, что это высокоприоритетная ошибка?

Там, где я работаю, у нас нет свободы выбора ОС, установки Ubuntu в Window или чего-то подобного.

@gombek вы пробовали v25? Команда Jest значительно улучшила производительность по всем направлениям.

Привет, просто подумал, что добавлю дополнительную информацию к этому обсуждению. Jest работает очень медленно, даже когда выполняется внутри контейнера Docker, который имеет исходный код и тесты, совместно используемые через том из хост-системы (Windows).

Я почти уверен, что это замедление связано с различиями в том, как Windows обрабатывает файлы, по сравнению с системами unix. В unix, если у процесса открыт дескриптор файла, который не блокирует чтение этого файла другими процессами. В Windows процесс, удерживающий дескриптор файла, владеет этим файлом до тех пор, пока он освобождает дескриптор. Я бы изучил код Jest для логики чтения файлов и особенно, когда и как освобождаются дескрипторы файлов. Хорошо работающая программа в любом случае должна выпускать дескрипторы файлов сразу после того, как выполнила свою работу. У тестового раннера, такого как Jest, в любом случае не должно быть причин долго удерживать дескриптор файла.

@gombek вы пробовали v25? Команда Jest значительно улучшила производительность по всем направлениям.

Я использую Jest v25 в Windows, но он все еще медленный

@pfftdammitchris Я сравнил довольно сложные наборы тестов на Mac + Windows и вижу некоторые различия, в основном из-за холодного кеша. Windows заметно медленнее, но когда становится жарко, я получаю одинаковую производительность между ними.

ТЕМ НЕ МЕНИЕ...

В частности, в Windows следует с особой осторожностью относиться к навязчивым программам уровня ядра, таким как антивирусы / средства отслеживания файлов, такие как Carbon Black (или другое программное обеспечение для просмотра файлов в реальном времени). Если у вас запущено что-то подобное, вы можете увидеть ОГРОМНОЕ снижение производительности при запуске Jest. Я говорю о том, что на выполнение тестов уходит десятки минут.

В прошлом году я работал в компании, где тот же набор тестов занимал ~ 30 секунд на Macbook Pro и 20 минут на ноутбуке с Windows с запущенными этими программами для просмотра файлов.

Понятия не имею, почему, но рискну предположить, что это как-то связано с дескрипторами файлов и тем, как Jest использует некоторые API файловой системы node.js.

У меня всего около 20 тестов, и я только что взял несколько таймингов с помощью jest --watch, как при начальном запуске, так и при нажатии Enter для их повторного запуска.

В Windows это заняло около 15 секунд оба раза, тогда как для Linux это было около 5,3 секунды при первом запуске и 2,3 секунды при последующих запусках.

Я пробовал использовать -t = "GARBAGE", чтобы пропустить все тесты. linux занял 1,5 секунды, но окна все еще заняли 13, поэтому мне кажется, что время занимает не фактическое выполнение тестов!

Обе машины используют последнюю версию node и jest, а linux на самом деле представляет собой виртуальную машину, работающую внутри Windows с использованием Hyper-v, поэтому при прочих равных я ожидал, что Windows будет быстрее.

У меня всего около 20 тестов, и я только что взял несколько таймингов с помощью jest --watch, как при начальном запуске, так и при нажатии Enter для их повторного запуска.

В Windows это заняло около 15 секунд оба раза, тогда как для Linux это было около 5,3 секунды при первом запуске и 2,3 секунды при последующих запусках.

Я пробовал использовать -t = "GARBAGE", чтобы пропустить все тесты. linux занял 1,5 секунды, но окна все еще заняли 13, поэтому мне кажется, что время занимает не фактическое выполнение тестов!

Обе машины используют последнюю версию node и jest, а linux на самом деле представляет собой виртуальную машину, работающую внутри Windows с использованием Hyper-v, поэтому при прочих равных я ожидал, что Windows будет быстрее.

Да. И если вы подключите исходные коды к виртуальной машине Linux из Windows и запустите тесты, они станут такими же медленными, как и в Windows. Это явно означает, что проблема заключается в логике обработки файлов Jest, о которой я упоминал ранее.

Да. И если вы подключите исходные коды к виртуальной машине Linux из Windows и запустите тесты, они станут такими же медленными, как и в Windows. Это явно означает, что проблема заключается в логике обработки файлов Jest, о которой я упоминал ранее.

Я заметил, что во время выполнения тестов загрузка ЦП высока, а использование диска - нет. Это было связано с блокировкой дескрипторов файлов, я ожидал, что это будет низкий процессор (если только шутка не находится в жестком цикле, ожидая освобождения дескрипторов)

Я видел комментарии hevans90 о наблюдателях файлов. У меня нет стороннего антивируса или аналогичного установленного, но отключение встроенной защиты Windows в режиме реального времени не дало заметной разницы.

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

Итак, сегодня я подтвердил, что Защитник Windows имеет огромное значение.
Раньше у меня была куча исключений, но когда я получил свой новый более быстрый ноутбук, я не мог понять, почему шутке требуется> 10 минут для запуска одного файла.

Потом я вспомнил об исключениях.
Я не могу точно сказать, какие исключения имеют значение, но я заставил бегуна опуститься до <15 секунд вместо> 10 минут

Я нашел суть с соответствующими исключениями (хотя и решительными)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
Я также добавил расширения файлов .ts .js .spec.ts .spec.js .tsx

Я не могу точно сказать, какие исключения имеют значение, но я заставил бегуна опуститься до <15 секунд вместо> 10 минут

хм, я просто попробовал это, и это, похоже, не имело для меня никакого значения (заметьте, у меня не было минут, поэтому, возможно, у нас другие проблемы)

В любом случае у меня всегда есть исключения. И на самом деле IntelliJ Idea автоматически предлагает поместить каталог рабочей области в исключения и сделает это за вас, если вы позволите (вы должны). Так что в моем случае медлительность не связана с Защитником Windows или каким-либо другим антивирусным сканером.

Разница в производительности в 5-10 раз по сравнению с Mac. ПК - это мощный настольный компьютер (читай: намного быстрее, чем macbook). Все остальное молниеносно, просто Jest страдает от этой проблемы.

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

Также есть эта проблема. Один тестовый файл с одним тестом hello world, запуск которого занимает ~ 15 секунд, плюс еще 12 секунд для запуска теста.

👋 Я вижу несколько ответов, намекающих, что они используют машинописный текст с jest - возможно, стоит изучить это (если вы также используете ts-jest): https://github.com/kulshekhar/ts-jest/issues/ 908 # issuecomment -484043250

Для меня изменение заключалось в том, чтобы ждать начала шутки 30 минут (без кеша) до нескольких секунд.

Имейте в виду, что установка флага isolatedModules не приведет к проверке типов ваших файлов спецификации (и потере некоторых функций): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

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

👋 Я вижу несколько ответов, намекающих, что они используют машинописный текст с jest - возможно, стоит посмотреть (если вы также используете ts-jest): kulshekhar / ts-jest # 908 (комментарий)

Для меня изменение заключалось в том, чтобы ждать начала шутки 30 минут (без кеша) до нескольких секунд.

Имейте в виду, что установка флага isolatedModules не приведет к проверке типов ваших файлов спецификации (и потере некоторых функций): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

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

Чистый JavaScript здесь. У меня эта проблема не связана с TypeScript.

К вашему сведению: https://github.com/kulshekhar/ts-jest/pull/1549 будет в альфа-версии ts-jest (возможно, сегодня). Любой, кто использует ts-jest, пожалуйста, помогите протестировать альфа-версию и поделитесь с нами своими отзывами по https://github.com/kulshekhar/ts-jest/issues/1115

Также есть эта проблема. Один тестовый файл с одним тестом hello world, запуск которого занимает ~ 15 секунд, плюс еще 12 секунд для запуска теста.

Просто запустил тот же тест на Mac. Для запуска требуется около 1,5 секунды, для запуска теста менее 1 секунды.

Также здесь используется JS, а не TS.

Здесь также есть чистый JavaScript с Jest. У меня есть мощный четырехъядерный ноутбук с процессорами Intel 10gen, и все остальное работает очень быстро, но [email protected] требует в 2-3 раза больше в Windows и Linux для выполнения некоторых базовых тестов.

Та же проблема, около 60 секунд для запуска моих тестов в Windows, и в течение первых 45 секунд или около того пользовательский интерфейс не отображается. Запустил тот же самый тестовый набор на моей Linux-машине, и его выполнение заняло 8 секунд.

Комментарий @Cellule выше резко ускорил процесс до примерно 15 секунд.

@ryanrapini последовал совету @Cellule (но прошел Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ) и увидел, что некоторые тесты ушли с 13 секунд до 6, то есть в основном наполовину. Благодаря!

Кто-нибудь хочет добавить раздел, в котором упоминается Защитник Windows (или антивирус в целом?) На странице часто задаваемых вопросов веб-сайта? https://jestjs.io/docs/en/troubleshooting

Я могу подтвердить, что использование isolatedModules: true с ts-jest дало ОГРОМНУЮ разницу при холодном запуске (~ 10 минут => 15 секунд)
Я не тестировал их улучшения в альфа-версии, потому что жду адреса # 9457 перед обновлением до jest 25.

Привет всем,

Такая же проблема здесь, и у меня нет решения ...

Я запускаю очень простой код, на котором у меня есть несколько тестов.
Это из «Курса Advanced React Course» Уэса Бо.
Он запускает его на Mac и сразу получает ответ со своего компьютера.

А для меня:

Наборы тестов: 2 пропущены, 15 пройдены, 15 из 17 всего
Тесты: 6 пропущено, 37 пройдено, 43 всего
Снимки: 18 пройдено, всего 18
Время: 5,869 с
Прогнал все наборы тестов.

isolatedModules: true в моем случае ничего не меняет, у меня все еще около 5-6 секунд.
И когда я начинаю тестирование с любым вариантом, это занимает 9 ~ 10 секунд.

Добавление моей папки dev в Исключения Защитника тоже ничего не дало:

Наборы тестов: 2 пропущены, 15 пройдены, 15 из 17 всего
Тесты: 6 пропущено, 37 пройдено, 43 всего
Снимки: 18 пройдено, всего 18
Время: 5.563 с
Прогнал все наборы тестов.

Есть ли хороший вариант в Windows?
Мне нужно переходить на wsl2?

Привет всем,

Такая же проблема здесь, и у меня нет решения ...

Я запускаю очень простой код, на котором у меня есть несколько тестов.
Это из «Курса Advanced React Course» Уэса Бо.
Он запускает его на Mac и сразу получает ответ со своего компьютера.

А для меня:

Наборы тестов: 2 пропущены, 15 пройдены, 15 из 17 всего
Тесты: 6 пропущено, 37 пройдено, 43 всего
Снимки: 18 пройдено, всего 18
Время: 5,869 с
Прогнал все наборы тестов.

isolatedModules: true в моем случае ничего не меняет, у меня все еще около 5-6 секунд.
И когда я начинаю тестирование с любым вариантом, это занимает 9 ~ 10 секунд.

Добавление моей папки dev в Исключения Защитника тоже ничего не дало:

Наборы тестов: 2 пропущены, 15 пройдены, 15 из 17 всего
Тесты: 6 пропущено, 37 пройдено, 43 всего
Снимки: 18 пройдено, всего 18
Время: 5.563 с
Прогнал все наборы тестов.

Есть ли хороший вариант в Windows?
Мне нужно переходить на wsl2?

Можете ли вы попробовать применить мое решение и сказать мне, помогает ли оно? (на самом деле решение Cellule, но я сделал это через меню, а не запускал скрипт)

Можете ли вы попробовать применить мое решение и сказать мне, помогает ли оно? (на самом деле решение Cellule, но я сделал это через меню, а не запускал скрипт)

Как я уже сказал в своем сообщении, я это уже сделал :)

Я имею в виду, что следил за тем, что вы сделали, через меню и все такое.

У меня тоже такая проблема с Windows. Сам тест выполняется менее чем за 1 секунду, но для выполнения общей настройки требуется ~ 15 секунд. Я пробовал это с v24 и v26, на самом деле он немного медленнее на v26

Мне не повезло ни с одним из следующего (это не улучшило время выполнения):

• добавление --runInBand
• установка maxWorkers
• добавление исключений .ts .js .spec.ts .spec.js .tsx в Virus and Threat Protection , как предложено @Cellule и @alessioalex

Та же проблема в Windows здесь с ванильным javascript, а также с новым проектом машинописного текста. 2 секунды для запуска 9 модульных тестов, которые выполняются менее 10 мс с использованием mocha.

Это безумие!

Просто установил jest по всему миру, и теперь точно такой же проект выполняется за 0,9 секунды вместо 52 (!!!) секунд!
npm remove jest в проекте, тогда
npm install -g jest

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

Это безумие!

Просто установил jest по всему миру, и теперь точно такой же проект выполняется за 0,9 секунды вместо 52 (!!!) секунд!
npm remove jest в проекте, тогда
npm install -g jest

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

Для меня это определенно звучит как проблема со сканером вирусов. Это означает, что каталог вашего проекта находится в области сканирования на вирусы, что замедляет сканирование, а глобальный каталог npm - нет. Это всего лишь предположение.

Я только что пробовал то же самое, что и @JPustkuchen, и производительность

Я исключил папку проекта из Защитника Windows, но Jest все еще работает медленно.

Я не знаю, работает ли это до сих пор, но я замечаю, что когда я делаю опечатку в коде, тесты в режиме просмотра мгновенно терпят неудачу. Это наводит меня на мысль, что на самом деле это не заставляет сканировать новый каталог перед компиляцией теста. У меня тоже очень простые тесты занимают 10 секунд.

Мне бы очень хотелось, чтобы кто-нибудь хотя бы признал, что это проблема. На данный момент мой настольный компьютер с Windows, обладающий большой мощностью (читай: гораздо больше, чем Macbook моих коллег), примерно в 69 раз медленнее, чем Macbook, при выполнении тестов! Это практически вынуждает меня не трогать код внешнего интерфейса, поскольку для меня неэффективно работать с ними из-за того, что тесты Jest работают так медленно. Возможно, нам придется отказаться от Jest, если это не будет исправлено. Все остальное происходит молниеносно, но тесты Jest очень медленные. Время тратится на что-то еще, кроме фактического выполнения тестов, когда выполняется фактическая логика тестирования, они проходят очень быстро.

В более позитивном плане, я просто хочу сказать, что я в долгу перед этой ошибкой. Это была последняя капля, которая заставила меня перейти на Linux в качестве основного рабочего процесса разработки, и я никогда не был так счастлив. Я не могу сказать, что никогда не вернусь, потому что иногда мне приходится работать над устаревшими проектами, но поскольку ядро ​​ASP.NET является кроссплатформенным, причин для обратной загрузки в Windows все время становится меньше.

Пожалуйста, @ timrobinson33, давайте продолжим тему. Нет причин, по которым jest должен быть в 68 раз медленнее, чем любая другая среда в Windows, учитывая, что Node отлично работает на любой платформе. Также могу добавить, у меня не было этой проблемы ни с одним другим средством запуска тестов.

Я тестировал v26.4.2 в моем репозитории jest github.
https://github.com/nasreddineskandrani/benchmark_jest
версия узла на моем компьютере: v12.13.0

довольно хорошо, когда я обновляю простой тест (см. скриншот)! Для меня шутка теперь верна для простого теста.
Если у вас есть проблемы на работе. Вам нужно попытаться изолировать проблему, так как по умолчанию все в порядке.

@empperi, можешь попробовать мой

Я тестировал v26.4.2 в моем репозитории jest github.
https://github.com/nasreddineskandrani/benchmark_jest
версия узла на моем компьютере: v12.13.0

довольно хорошо, когда я обновляю простой тест (см. скриншот)! Для меня шутка теперь верна для простого теста.
Если у вас есть проблемы на работе. Вам нужно попытаться изолировать проблему, так как по умолчанию все в порядке.

@empperi, можешь попробовать мой

Как и ожидалось, никакой разницы в производительности вашей тестовой установки. На самом деле работает немного быстрее, чем на вашем компьютере. Изменили настройку теста, чтобы она содержала 100 тестовых файлов под __tests__ и они тоже работают нормально. Поскольку в нашем приложении используется react-scripts я также добавил это в ваш пример, чтобы проверить, может ли это вызвать реальную проблему, но без разницы в производительности.

ОДНАКО затем я попытался запустить эти тесты в WSL2 bash (против файловой системы NTFS) и бум, время выполнения почти в 10 раз для raw powershell. На WSL2 следует ожидать более медленную скорость ввода-вывода по сравнению с NTFS, но, учитывая, насколько проста эта настройка (всего 100 тестовых файлов с одним тестом для каждого), это действительно не должно сильно влиять. Для справки, я выполнил это на WSL2 bash:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

Это показывает, что чтение файловой системы из WSL2 практически не занимает времени. Для справки аналогичная команда в Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

Это показывает, что производительность примерно такая же.

Итак, исходя из этого, я бы сказал, что проблема может быть вызвана тем, как Jest использует ввод-вывод, и это как-то сильно влияет на производительность WSL2. Когда дело доходит до проекта, который вызывает у меня проблемы, непросто не требовать bash из-за проблем в коде и тестах (не мной!). Учитывая тот факт, что WSL2 набирает популярность, я бы сказал, что это реальная проблема, на которую следует обратить внимание.

Надеюсь это поможет.

:редактировать:

Просто из любопытства я выполнил наш набор тестов с помощью --no-watch чтобы посмотреть, влияет ли на что-то наблюдение файловой системы через WSL2. Ответ - нет, на самом деле это не так сильно влияет.

Запуск теста на моем компьютере с Windows занимает около 1,6 секунды. Я не использую WSL.
Я использую антивирус AVG, но добавил исключения как для репозитория, так и для исполняемого файла узла.
Мой жесткий диск - SSD.

Версия узла: v12.16.1

Обновление теста мгновенно запускает средство отслеживания файлов, но фактическое время, необходимое для запуска этого обновления, составляет около 1–2,4 секунды.

Я хотел проверить, не проблема ли в окружающей среде.

Я возился с этим репо: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• Я выбираю npm test и все тесты запускаются в режиме просмотра.
• Я нажимаю "p", чтобы ввести шаблон для файла, и набираю "tdd-02". Я получаю время выполнения более 3 секунд.
  

Я был бы удивлен, если бы у Кента С. Доддса была испорченная среда в его платном курсе, но если он это сделает, вы, вероятно, сможете отладить его там:? В его видеороликах все работает нормально, я думаю, он использует Mac.

Я должен отметить кое-что очень странное, что я не могу воспроизвести снова - у меня было несколько последовательных тестовых запусков, которые для одного из файлов (tdd-02 ... js) выполнялись в течение примерно 0,1 с, а для файла рядом с ним ( tdd-01 ... js) - около 3сек. Код почти такой же и использует те же зависимости. Итак, я скопировал код из быстро работающего файла и вставил его в медленно работающий и наоборот. Результаты были такими же: медленно работающий файл оставался медленным, а быстро работающий файл оставался быстрым, а фактические коды менялись местами. Это сходит с ума. Теперь оба файла снова работают медленно (3-6 с).

@Glinkis вы можете попробовать нажать Enter после первого запуска, он все еще отображается в 1,6 секунды? (запустить повтор)

@SimeonRolev, я посмотрю на опубликованный вами пример и посмотрю, какой номер я получу с теми же шагами (шаблон ...)
Обновить:
try1: я попробовал это я, как и, и получил 6 секунд, когда попробовал ваши шаги -> упасть до 3 секунд при повторном запуске того же теста (нажмите Enter)
try2: обновлено jest до 26,4 в репозитории Kent -> 3 секунды при первом запуске рядом с тем же для повторного запуска
try3: я взял файл index.spec.js из репозитория для тестирования производительности. и я бросил его в репо Кент. (удаление всех других тестовых файлов) -> сюрприз 2,8 секунды (ЖЕ JEST 26.4.2, ЖЕ КОМПЬЮТЕР, POWERSHELL, NODE_VERSION и т. д., как мой тест вчера опубликовал здесь)

Я не понимаю этого try3 еще => ~ 3сек на перекладки в Кент репо для моего файла ,
edit: Кент должен быть тем, кто это проверяет: P

Нажатие клавиши ввода приводит к запуску теста примерно через 200 мс.

@nasreddineskandrani А ты наоборот пробовал? То есть копирование тестов из медленного репо в ваше? Но я не думаю, что проблема в репо, которое я опубликовал. Как мы ясно видим, у многих людей такая же проблема, я просто опубликовал воспроизводимый пример.

@kentcdodds Будете ли вы еще раз нашим героем?

@SimeonRolev В моем тесте я не вижу той же проблемы, что и в

Эта проблема с github связана с окнами производительности Jest по сравнению с macOS / Linux, поскольку они не достигли той же производительности. они не сделали оговорку, я думаю. (сейчас намного лучше, чем 2 года назад с jest v23)

Здравствуйте, у меня здесь такая же проблема. У меня есть машина с Windows и WSL. Я скопировал файлы своего проекта в WSL, чтобы проверить это поведение. Вот прогоны тех же двух основных тестов:
Windows 10 (версия 2004):

WSL 2 (Ubuntu 20.04):

Тесты очень простые:

Проект создан с помощью CRA, поэтому здесь нет конфигурации, чтобы испортить настройки, я ничего не добавил в плане Jest.
Те же тесты выполняются на мокко невероятно быстро, почти мгновенно. Я пытаюсь настроить среду тестирования для нашего проекта, и мне бы очень хотелось использовать Jest, но кажется, что по мере того, как я добавляю все больше и больше тестов, набор тестов будет все медленнее и медленнее, как кажется. Кажется, что каждый тест добавляет 0,8 секунды, что нелепо, поскольку они ничего не делают. Что-то мешает выполнению тестов в Windows, и я не знаю что.
Проблема была хуже, один тест занимал около 15 секунд, но когда я добавил --runInBand и, ситуация, казалось, немного улучшилась, но я думаю, что этого все еще недостаточно, учитывая, что режим просмотра мокко работает мгновенно.

Yarn - это версия 1.22.5, все остальные зависимости npm (например, сценарии реакции и реакции) являются последними.

Я отключил антивирус и защитник Windows, чтобы посмотреть, действует ли он, но это не так. Кроме того, я отключил индексацию для своей папки проекта, но безрезультатно.

Изменить: я попытался нажать клавишу ввода, и тесты были такими же быстрыми, как на WSL:

Теперь я совсем запуталась :)

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

Изменить 2: когда я добавил 100 тестов в свой набор тестов, на их запуск ушло около 44 секунд, даже если я нажму ввод, чтобы запустить их:

Тот же набор тестов занимает около 9-10 секунд на WSL: