jest 🚀 - Jest는 모든 Windows 시스템 (Windows 10 이하)에서 3 배 느립니다.

처음 1.7 초의 스크린 샷 :

first_1 7secs

1.8 초 ~ 2.7 초 스크린 샷

기록 후 ndb의 프로필 탭에서 저장된 .json 파일 및 .heapsnapshot 파일 :

pfftdammitchris 에 2019년 01월 15일

👍2

@pfftdammitchris 느리다 는 것을 알게 된 [정확한] 사용
(하나의 파일 또는 여러 파일)? (시계 모드 또는 아니오)? 예제를 제공 할 수 있습니까?
하나의 파일 감시 모드 문제 => # 6783의 마지막 댓글을 읽으십시오.

nasreddineskandrani 에 2019년 01월 26일

감시 모드의 유무에 관계없이 단일 및 다중 파일 모두 느립니다. 거의 모든 테스트를 실행할 때마다 테스트 초기화에 3 초 이상의 지연이 있으며, 테스트를 하나씩 실행하는 속도가 0.3 초 또는 0.4 초 또는 0.5 초 느리지 만 mocha / chai와 같은 다른 테스트 실행자는 일반적으로 실행됩니다. 각각 0.05 초처럼 느껴집니다.

나는 codesandbox에서 jest를 사용하고 초기화 / 실행 테스트에서 즉시 jest를 실행하는 것처럼 보이며 동료들이 Mac 컴퓨터에서 농담을 실행하는 것을 보았고 평소처럼 즉시 실행합니다. 내가 아는 한 그것은 단지 Windows 기계입니다. 나는 직장에서 Windows 기계를 사용하고 농담이 느린 문제를 겪고 있으며 집에서도 Windows 기계를 사용하고 문제는 여기에서 계속됩니다.

--runInBand를 사용했지만 느낌에 따라 단위 테스트 속도가 각각 0.2 초씩 더 느려진 것 같습니다.

pfftdammitchris 에 2019년 01월 31일

👍11

설명

--runInBand를 사용했지만 느낌에 따라 단위 테스트 속도가 각각 0.2 초씩 더 느려진 것 같습니다.

=> v24로 시도하셨습니까? v23에서 v24로이 시나리오에서만 좋은 개선 사항을 확인할 수 있습니다.
_ rerun 에서 watch 및 한 파일에 대해 실행하는 경우에만 (첫 실행 시가 아님) _
-> 2/3 초가 0.4 / 0.5 초로 떨어집니다.
하지만 Mac에 비해 시도한 적이 없습니다 ... 그래서 어쩌면 그것은 여전히 나쁩니다 ... 현재의 개선에도 불구하고

뿡뿡

모든 문제가있는 시나리오에 대해 Windows에서 https://github.com/facebook/jest/issues/7110 을 Jest 속도 회귀 [v22 대 v23]로 간주합니다.
# 6783은 그중 하나입니다.

2.이 문제를 다음과 같이 생각할 수 있습니다. 모든 문제 시나리오에 대한 농담 속도 문제 [Mac 대 Windows].

nasreddineskandrani 에 2019년 02월 02일

모두들 안녕 !
나는 jest 24와 windows 10의 느린 속도를 누적합니다 (400 개의 테스트에 800 초!). 이 모든 속도를 높이는 가장 빠른 방법은 powershell 또는 cmd 대신 wsl을 사용하는 것입니다. 이제 내 테스트는 "단지"189 초가 걸립니다.

Darkein 에 2019년 03월 15일

Windows 10 빌드 15063 시스템, Core i7 (16GB)에서 실행하는 데 1 분 43 초가 걸리는 1302 개의 테스트가 포함 된 144 개의 테스트 파일 모음이 있으며 32GB의 MAC OS Mojave에서는 28 초가 걸립니다. 우리 개발 팀은 Windows와 Mac간에 균등하게 분할되어 있으며 그 숫자는 매우 반복적입니다.

kensherman 에 2019년 04월 16일

다음은 간단한 테스트입니다.

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

내가 codesandbox에 넣어하고 즉시 꽤 많이 실행 - https://codesandbox.io/s/4q8l0q52lw

내 Windows 컴퓨터에서는 4-5 초가 걸립니다.

PASS src / index.test.js
v 작동 (62ms)
테스트 스위트 : 1 개 통과, 총 1 개
테스트 : 1 개 통과, 1 개 총
스냅 샷 : 총 0 개
시간 : 4.158 초
모든 테스트 스위트를 실행했습니다.

테스트 자체는 62ms가 걸렸지 만 나머지 테스트 장치는 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 에 2019년 05월 01일

@bburns 는 위의 문제를 읽었습니다.

헉헉
실 해상도에서 micromatch 4로 시도해 볼 수 있습니까? 창문에서 더 나은지 확인하십시오.
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

nasreddineskandrani 에 2019년 05월 01일

저는 새로운 MacBook Pro를 사용하고 있습니다. MacOS와 Windows 10을 모두 사용하는 학생이 있으므로 드라이브에 파티션을 두 개 더 추가하기로 결정했습니다. 하나는 Windows 10 용이고 다른 하나는 Tuxera NTFS를 사용하는 공유 스토리지 용입니다.

저는 오늘 단위 테스트를 통합하는 JavaScript 강의를 준비하면서이 속도 문제에 직면했습니다. 실제로 MacOS에서 Jest를 실행하고 있지만 코드와 테스트는 공유 NTFS 파티션에 있습니다. 모든 제품군이 describe.skip 로 표시된 경우에도 Jest는 단일 실행 모드와 감시 모드 모두에서 완료하는 데 10 초 이상 걸립니다.

8 개 스위트
42 회 테스트

jest 를 mocha 와 chai 바꾸었고 실행은 약 1 초 단일 및 10 밀리 초 시계 모드로 돌아 왔습니다.

thebearingedge 에 2019년 05월 28일

👍11 👎7

나는 농담을 mocha와 chai로 바꾸고 약 1 초의 싱글과 10 밀리 초의 시계 모드로 돌아왔다.

기본적으로 당신은 내 마지막 게시물을 읽지 않았습니다. 당신은 mocha/chai 를 홍보하고 싶었습니다 ... 우리 모두는 이것에 대해 알고 있습니다 ... 우리는 농담의 회귀를 수정하려고 노력하고 있습니다. [내 게시물에서] ...can you try with micromatch 4... 이 작업을 돕거나 쓸모없는 댓글을 스레드에서 제외 시키십시오. 직접적으로 미안하지만 언젠가는 그것을 말할 다른 방법이 없습니다.

nasreddineskandrani 에 2019년 05월 28일

👍6

@nasreddineskandrani 나는 시도하고 [email protected]을 하지만, 어떤 도움이 많이 주시면 감사하겠습니다 감시 모드로 실행할 때 난 여전히 매우 느리게 실행을 볼 수 있습니다.

pachumon 에 2019년 06월 14일

@pachumon 수정 사항은 내가 이해하는 한 24.8.0에 없습니다.

성능 문제를 제거하기 위해 특정 버전에 대한 jest 종속성 하나를 설정해야합니다 (이론적으로) 수정 사항은 기본적으로 jest 25 => 개발자가 https://github.com/을 찾는 방법을 알기 위해 여기에서 읽을 수

종속성 (마이크로 매치)을 수정이 완료된 버전으로 설정하려면 => 여기에서 확인할 수 있습니다. 작은 프로젝트에서 예제를 수행했습니다.
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

package.json 추가하십시오 : ( yarn 아니라 npm yarn 사용해야합니다)

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

도움이 되었기를 바랍니다! 그리고 피드백을 기다리고

nasreddineskandrani 에 2019년 06월 15일

👍2

내 테스트 실행 시간도 23.6.0의 2.5 분에서 24.7.1 및 24.8.0의 15 분으로 늘어났습니다. CI 서버는 윈도우를 실행하고 있으며이 업그레이드로 빌드 시간이 비슷하게 크게 증가했습니다. @nasreddineskandrani 가 위에 언급 한대로 micromatch 종속성 해결 재정의를 시도했지만 아무 소용이 없습니다. 이 문제를 진단하는 데 도움이 필요하면 알려주세요.

TomMahle 에 2019년 07월 02일

😕1

@TomMahle 이것은 매우 나쁜 newz입니다 :( (우리가 이야기하고있는 회귀는 이미 23.6에있었습니다)
지금은 간단한 '샘플'프로젝트가 좋은 성능을 보여주었습니다. 마이크로 매치 업데이트 후.
디버깅 할 실제 문제가있는 프로젝트가 필요합니다. 프로젝트가 비공개입니까? 아니면 공개?

nasreddineskandrani 에 2019년 07월 04일

micromatch @nasreddineskandrani 에 대한 제안에 감사하지만 위의 @TomMahle 과 마찬가지로 ^4.0.0 고정해도 성능이 향상되지 않는 것 같습니다. 😢

하지만이 문제를 진단하는 데 도움이 될 수있는 한 가지 펑키 한 것을 발견했습니다.

내 Windows 파일 시스템에서 마운트 된 기본 앱 디렉토리가있는 도커 컨테이너에서 기본 Windows 시스템에서 jest를 실행할 수 있습니다. 비감시 모드에서 실행하는 것은 두 시스템에서 거의 동일한 동작을 보이는 것 같습니다. 리눅스 VM.

그러나 watch 모드에서는 상황이 약간 다릅니다. 기본 창은 항상 예상대로 느리게 작동하지만 docker 컨테이너 는 처음 실행할 때만 느리게 테스트를 p 를 누르고 패턴을 입력하여) 1 초 이내에 테스트를 실행합니다 (기본 창에서 동일한 작업을 수행하는 데 3-4 초가 걸립니다). 도커 사용의 유일한 단점은 파일 변경 이벤트가 내 Windows 볼륨에서 도커로 전파되지 않는 것 같으므로 자동으로 수행하는 대신 Enter 키 를 눌러 테스트를 다시 실행해야한다는 것입니다. 당면한 문제와 관련이 없습니다.

toolness 에 2019년 07월 06일

😕1

안녕하세요. 불행히도 내 프로젝트는 비공개입니다. 더 작은 코드 샘플 (Jest config?)이 있거나 통계를 제공 할 수 있다면 기꺼이 그렇게 할 수 있습니다. 모든 테스트는 (윈도우에서만) 극적으로 느린 것 같아서 특정 테스트와 관련이 없다고 생각합니다.

TomMahle 에 2019년 07월 06일

나는 내 개인 웹 사이트를 위해하고있는 도커 작업을 마무리하고있다-> (1 주일 후에) 나는 이것에 대해 다시 올 것이다.

뿡뿡
나는 당신이 설명하는 문제와 함께 repo github를 갖기 위해 내 편을 시도 할 것입니다.

얼마나 많은 검사를 받았습니까?
테스트를 위해 dom 모드를 활성화하고 있습니까?
반응인가, 각도인가?
보너스:
디버깅 할 수 있도록 github repo에서 문제를 재현 할 수 있습니까?
내 포크 : https://github.com/nasreddineskandrani/benchmark_jest
또는
테스트 머신에서 내 repo를 시도해 볼까요? 결과를 보시겠습니까? 23.6에서 24 사이

nasreddineskandrani 에 2019년 07월 08일

👀1

나는 마이크로 매치의 메인테이너들에게 충분히주의를 기울 였기 때문에이 문제는 이미 해결 된 것 같다. Windows에서 농담 테스트를 실행하는 것은 현재 매우 불쾌한 경험입니다.

kostadinnm 에 2019년 07월 10일

👀1 👍1

나는 그 이후로 mocha / chai로 옮겼지만이 문제가 여전히 해결되고 있다는 것에 놀랐습니다.

설명
--runInBand를 사용했지만 느낌에 따라 단위 테스트 속도가 각각 0.2 초씩 더 느려진 것 같습니다.
=> v24로 시도하셨습니까? v23에서 v24로이 시나리오에서만 좋은 개선 사항을 확인할 수 있습니다.
_ rerun 에서 watch 및 한 파일에 대해 실행하는 경우에만 (첫 실행 시가 아님) _
-> 2/3 초가 0.4 / 0.5 초로 떨어집니다.
하지만 Mac에 비해 시도한 적이 없습니다 ... 그래서 어쩌면 그것은 여전히 나쁩니다 ... 현재의 개선에도 불구하고
뿡뿡
모든 문제가있는 시나리오에 대해 Windows에서 # 7110을 Jest 속도 회귀 [v22 대 v23]로 간주합니다.
# 6783은 그중 하나입니다.
2.이 문제를 다음과 같이 생각할 수 있습니다. 모든 문제 시나리오에 대한 농담 속도 문제 [Mac 대 Windows].

나는 게시물 당시 두 버전을 모두 시도했습니다.

방금 간단한 배열 푸시 테스트로 하나의 테스트로 새 프로젝트를 만들었는데 시작부터 완료까지 10 초 이상 걸렸습니다. 프로젝트는 react / typescript를 사용하고 있지만 테스트 파일은 react 컴포넌트 파일이 아니라 .js와 같은 일반 파일입니다. 문제가 무엇인지 시각화하는 것이 더 나은 경우 시각적 참조를 위해 아래 GIF를 :

테스트를 처음 실행할 때 테스트가 9 초로 추정되는 것으로 나타났습니다. 완료되면 완료 될 때까지 두 번째 테스트를 무작위로 재 시도 합니다.

위의 gif 사진을 찍었을 때 (이번에 두 번째) 예상 시간이 약간 줄어들었고 두 번째 재 시도를 수행하지 않았습니다. 그것이 예상되는 농담 행동인지 확실하지 않습니다.

다음은 별도의 프로젝트에서 yarn으로 micromatch 4를 실행하는 저의 gif입니다.

Windows 10 및 내 컴퓨터 사양을 사용하는 경우 :
AMD FX (tm) -8320 8 코어 프로세서 3.50GHz
16GB 램
x64
SSD

pfftdammitchris 에 2019년 07월 13일

👀4

여기서 제 프로파일 링을 공유하겠습니다.
명세서:

Windows 10 Pro
노드 10.15.3
인텔 코어 i7-4702MQ 2.2GHz
8GB RAM
x64
SSD

단계 :

npx create-react-app my-app --typescript
App.test.tsx
npm test

CPU 프로필 :

CPU-20190801T141211.zip

사소한 단일 React 구성 요소 및 테스트를위한 모듈을 요청하는 데 15 초만 소요될 것으로 예상됩니까?

CPU 프로파일 링에 대해 더 많은 경험이있는 사람이 살펴볼 수 있습니까?

mucsi96 에 2019년 08월 01일

112 회
윈도우 10
첫 실행 507 초
두 번째 실행 23 초
리눅스 서브 시스템
54 초의 프리스트 런
두 번째 실행 29 초

85 번의 테스트
윈도우 10
첫 실행 44 초
두 번째 실행 15 초
리눅스 서브 시스템
첫 실행 26 초
두 번째 실행 15 초

Kepro 에 2019년 08월 01일

Kepro이 결과는 micromatch 4와 함께 있습니까?

여기에 1 백만 개의 메시지를 보내는 것보다 직접 채팅을 선호합니다. 동일한 주제와 관련된 모든 문제를 따라가는 것이 정말 지옥이되고 있습니다.
여기에서 가입 할 수 있습니다. https://gitter.im/wearefrontend/jest-slow-windows
지금하고 있어요 ...

nasreddineskandrani 에 2019년 08월 02일

Gitter는 내 회사 VPN을 통해 차단됩니다. 사랑스러운 사람들이 여기에 의미있는 업데이트를 게시 할 수 있다면 놀라운 일이 될 것입니다. <3

hevans90 에 2019년 08월 08일

여전히 집에서 연결하여 오픈 소스를 할 수 있습니다.
추신 dota 게임은 대기열에 더 많은 시간이 소요됩니다. 이제 gitter를 확인할 수 있습니다.)
현재 위치 : nodejs / node # 28946

nasreddineskandrani 에 2019년 08월 09일

트윗 담아 가기 나는 새로운 맥북을 주문 했으므로 그것이 도착할 때까지 오픈 소스 작업에서 벗어날 것입니다. 나는 여가 시간에 내 엉뚱한 Windows 상자에서 실제로 작업하는 것을 거부합니다.

문제가 노드 / C ++ 영역으로 이동 한 것 같습니다.이 영역은 내 안전 지대를 약간 벗어난 것입니다.

hevans90 에 2019년 08월 20일

👀1

안녕하세요 이것에 대한 소식이 있습니까?

해결 방법으로 여러 테스트를 시작하는 경우 --runInBand를 사용할 수 있습니다. 첫 번째 테스트를 시작하는 데 여전히 오랜 시간이 걸리지 만 다음 테스트는 빠릅니다.

내 프로젝트는 모든 테스트를 실행하는 데 21.803 초가 걸렸습니다.
이제 --runInBand를 사용하면 7.412 초만 걸립니다.

DiabolusExMachina 에 2019년 09월 11일

🎉1

--runInBand는 그냥 더 느리게 만듭니다. 1200 테스트. runinBand 70/50 초없이. --runInBand를 사용하면 두 번째 실행에서 기껏해야 90 초
리눅스에서는 5-8 배 더 빠름

aldarund 에 2019년 10월 24일

그런 다음 --maxWorkers = 4를 시도하십시오.

cino893 에 2019년 11월 15일

@ cino893 , 해결책이 아닙니다 :) 해결 방법이 아닌 수정을 찾으십시오.

Kepro 에 2019년 11월 15일

👍7

그것에 대한 소식은 없나요? 그 버그로 인해 버전 21에 쌓였습니다. v22는 느리고 v23은 더 느립니다.
우선 순위가 높은 버그라고 생각하지 않습니까?

내가 일하는 곳에서는 OS를 선택하거나 Windows 또는 이와 유사한 것에 Ubuntu를 설치할 자유가 없습니다.

gombek 에 2020년 02월 25일

@gombek v25 를 사용해 보셨습니까? Jest 팀은 전반적으로 성능을 많이 개선했습니다.

hevans90 에 2020년 03월 02일

안녕하세요,이 토론에 몇 가지 추가 정보를 추가하겠다고 생각했습니다. Jest는 호스트 시스템 (Windows)의 볼륨을 통해 공유 된 소스 코드와 테스트가있는 Docker 컨테이너 내부에서 실행될 때도 매우 느립니다.

이 속도 저하는 Windows가 유닉스 시스템과 비교하여 파일 핸들을 처리하는 방식의 차이로 인한 것이라고 확신합니다. 유닉스에서 프로세스에 다른 프로세스가 해당 파일을 읽는 것을 차단하지 않는 파일 핸들이 열려있는 경우. Windows에서 파일 핸들을 보유한 프로세스는 핸들을 해제하는 한 해당 파일을 소유합니다. 파일 읽기 논리, 특히 파일 핸들이 릴리스되는시기와 방법에 대해 Jest 코드를 살펴 보겠습니다. 잘 작동하는 프로그램은 작업이 완료된 직후 파일 핸들을 해제해야합니다. Jest와 같은 테스트 실행기는 어쨌든 오랫동안 파일 핸들을 유지할 이유가 없어야합니다.

empperi 에 2020년 03월 06일

👍5

@gombek v25 를 사용해 보셨습니까? Jest 팀은 전반적으로 성능을 많이 개선했습니다.

Windows에서 Jest v25를 사용하고 있지만 여전히 느립니다.

pfftdammitchris 에 2020년 03월 06일

@pfftdammitchris 저는 Mac + Windows에서 꽤 복잡한 테스트 스위트를 비교

하나...

Windows에서 특히주의해야 할 사항 중 하나는 Carbon Black (또는 기타 실시간 파일 감시 소프트웨어)과 같은 바이러스 백신 / 파일 감시자와 같은 침입 커널 수준 프로그램입니다. 이와 같은 실행이 있으면 Jest를 실행할 때 엄청난 성능 저하를 볼 수 있습니다. 테스트를 실행하는 데 수십 분이 걸린다는 이야기입니다.

저는 작년에 같은 테스트 스위트가 Macbook Pro에서 30 초, Windows 랩톱에서 20 분이 걸리며 이러한 파일 감시 프로그램이 실행되는 회사에서 일했습니다.

왜 그런지 모르겠지만 파일 핸들과 관련이 있으며 Jest가 node.js 파일 시스템 API 중 일부를 사용하는 방법을 추측 할 수 있습니다.

hevans90 에 2020년 03월 06일

👍2

나는 약 20 개의 테스트만을 가지고 있으며, 초기 실행에서 두 가지 모두에서 농담으로 타이밍을 잡은 다음 Enter 키를 눌러 다시 실행했습니다.

Windows에서는 두 번 모두 약 15 초가 걸렸지 만 Linux에서는 처음 실행시 약 5.3 초, 후속 실행에서는 2.3 초가 소요되었습니다.

-t = "GARBAGE"를 사용하여 모든 테스트를 건너 뛰도록했습니다. 리눅스는 1.5 초가 걸렸지 만 창은 여전히 13 초가 걸렸기 때문에 시간이 걸리는 것은 실제 테스트 실행이 아닌 것 같습니다!

두 컴퓨터 모두 최신 버전의 node와 jest를 사용하고 있으며 Linux는 실제로 hyper-v를 사용하여 Windows 내부에서 실행되는 VM이므로 다른 것들이 동일하면 Windows가 더 빠를 것으로 예상합니다.

timrobinson33 에 2020년 03월 29일

나는 약 20 개의 테스트만을 가지고 있으며, 초기 실행에서 두 가지 모두에서 농담으로 타이밍을 잡은 다음 Enter 키를 눌러 다시 실행했습니다.
Windows에서는 두 번 모두 약 15 초가 걸렸지 만 Linux에서는 처음 실행시 약 5.3 초, 후속 실행에서는 2.3 초가 소요되었습니다.
-t = "GARBAGE"를 사용하여 모든 테스트를 건너 뛰도록했습니다. 리눅스는 1.5 초가 걸렸지 만 창은 여전히 13 초가 걸렸기 때문에 시간이 걸리는 것은 실제 테스트 실행이 아닌 것 같습니다!
두 컴퓨터 모두 최신 버전의 node와 jest를 사용하고 있으며 Linux는 실제로 hyper-v를 사용하여 Windows 내부에서 실행되는 VM이므로 다른 것들이 동일하면 Windows가 더 빠를 것으로 예상합니다.

예. Windows에서 Linux VM에 소스 코드를 마운트하고 테스트를 실행하면 Windows 에서처럼 느려집니다. 이것은 앞서 언급 한 것처럼 Jest의 파일 처리 로직에 문제가 있음을 강력하게 암시합니다.

empperi 에 2020년 03월 29일

예. Windows에서 Linux VM에 소스 코드를 마운트하고 테스트를 실행하면 Windows 에서처럼 느려집니다. 이것은 앞서 언급 한 것처럼 Jest의 파일 처리 로직에 문제가 있음을 강력하게 암시합니다.

테스트가 실행되는 동안 CPU는 높지만 디스크 사용량은 그렇지 않다는 것을 알았습니다. 파일 핸들에 대한 차단과 관련이 있었으므로 CPU가 낮을 것으로 예상합니다 (조작이 핸들이 해제되기를 기다리는 타이트한 루프에 있지 않는 한)

파일 감시자에 대한 hevans90의 댓글을 봤습니다. 타사 바이러스 백신이 설치되어 있지 않거나 이와 유사한 기능이 설치되어 있지 않지만 Windows 기본 제공 실시간 보호를 비활성화해도 눈에 띄는 차이는 없습니다.

시도하고 디버깅 할 시간이있는 사람에게 도움이 되었으면합니다.

timrobinson33 에 2020년 03월 29일

그래서 오늘 Windows Defender가 큰 차이를 만든다는 것을 확인했습니다.
예전에는 많은 예외가 있었지만 더 빠른 노트북을 받았을 때 jest가 단일 파일을 실행하는 데 10 분 이상 걸린 이유를 평생 알 수 없었습니다.

그런 다음 예외를 기억했습니다.
어떤 제외가 차이를 만드는지 정확히 알 수는 없지만 러너는 10 분을 넘지 않고 15 초로 줄였습니다.

관련 제외 항목이있는 요점을 찾았습니다 (강력하지만)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
파일 확장자 .ts .js .spec.ts .spec.js .tsx 도 추가했습니다.

Cellule 에 2020년 03월 30일

👍1

어떤 제외가 차이를 만드는지 정확히 알 수는 없지만 러너는 10 분을 넘지 않고 15 초로 줄였습니다.

흠 나는 방금 시도했지만 내 것과 아무런 차이가없는 것 같습니다.

timrobinson33 에 2020년 03월 30일

어쨌든 항상 예외가 있습니다. 실제로 IntelliJ Idea는 작업 공간 디렉토리를 제외에 자동으로 배치하도록 제안하고 허용하는 경우이를 수행합니다 (필요한 경우). 따라서 제 경우에는 속도 저하가 Windows Defender 또는 다른 바이러스 스캐너로 인한 것이 아닙니다.

성능 차이는 Mac에 비해 5 ~ 10 배입니다. PC는 강력한 데스크톱 컴퓨터입니다 (읽기 : 맥북보다 훨씬 빠름). 다른 모든 것은 번개처럼 빠르며 Jest 만이 문제로 고통 받고 있습니다.

empperi 에 2020년 03월 30일

이것에 대한 업데이트가 있습니까? ... 나는 똑같은 일을 겪고 있는데, 각 테스트는 설정하고로드하는 데 오랜 시간이 걸리지 만 첫 번째 테스트가로드 된 후에는 정상적인 속도로 실행됩니다 .....

wickstargazer 에 2020년 04월 18일

또한이 문제가 있습니다. 단일 hello world 테스트가 포함 된 단일 테스트 파일이며 시작하는 데 15 초가 걸리고 테스트를 실행하는 데 12 초가 더 걸립니다.

JamesCatt 에 2020년 04월 19일

👋 나는 그들이 jest와 함께 typescript를 사용하고 있음을 암시하는 몇 가지 답변을 봅니다-이것은 살펴볼 가치가있을 수 있습니다 (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

귀하의 문제가 농담인지 확인하는 데 유용 할 수 있으므로 여기에만 게시합니다.

kreatemore 에 2020년 04월 20일

👋 나는 그들이 jest와 함께 typescript를 사용하고 있음을 암시하는 몇 가지 답변을 봅니다 .
저에게 변화는 (캐시없이) 농담이 시작될 때까지 30 분을 기다리는 것에서 불과 몇 초로 진행되었습니다.
isolatedModules 플래그를 설정하면 사양 파일에 대한 유형 검사가 수행되지 않으며 일부 기능이 손실됩니다. https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md
귀하의 문제가 농담인지 확인하는 데 유용 할 수 있으므로 여기에만 게시합니다.

여기에 순수한 JavaScript. 이 문제는 TypeScript와 관련이 없습니다.

empperi 에 2020년 04월 20일

👍1

참고 : https://github.com/kulshekhar/ts-jest/pull/1549 는 ts-jest의 알파 버전입니다 (아마 오늘). ts-jest를 사용하는 사람은 알파 버전을 테스트하고 https://github.com/kulshekhar/ts-jest/issues/1115에 대한 의견을 보내주세요.

ahnpnl 에 2020년 04월 21일

👍1

또한이 문제가 있습니다. 단일 hello world 테스트가 포함 된 단일 테스트 파일이며 시작하는 데 15 초가 걸리고 테스트를 실행하는 데 12 초가 더 걸립니다.

Mac에서 동일한 테스트를 실행했습니다. 시작하는 데 약 1.5 초, 테스트를 실행하는 데 1 초 미만이 걸립니다.

여기 TS가 아닌 JS도 사용합니다.

JamesCatt 에 2020년 04월 21일

Jest와 함께 순수한 JavaScript도 여기에 있습니다. 인텔의 10 세대 프로세서를 탑재 한 강력한 쿼드 코어 노트북이 있고 다른 모든 것은 매우 빠르지 만 몇 가지 기본 테스트를 실행하는 데 Windows와 Linux에서 [email protected] 가 2-3 배 더 많이 걸립니다.

alessioalex 에 2020년 04월 21일

동일한 문제, 내 테스트가 Windows에서 실행되는 데 약 60 초가 걸리며 처음 45 초 동안 UI가 표시되지 않습니다. 내 리눅스 컴퓨터에서 똑같은 테스트 스위트를 실행했고 완료하는 데 8 초가 걸렸습니다.

위의 @Cellule 의 댓글은 약 15 초까지 극적으로 빨라졌습니다.

ryanrapini 에 2020년 04월 23일

@ryanrapini 는 @Cellule 의 조언을 따랐지만 ( Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions 통과했습니다) 일부 테스트가 13 초에서 6 초로, 기본적으로 절반이되는 것을 확인했습니다. 감사!

alessioalex 에 2020년 04월 25일

웹 사이트의 FAQ 페이지에서 Windows Defender (또는 일반적으로 AV?)를 언급하는 섹션을 제공하고 싶은 사람이 있습니까? https://jestjs.io/docs/en/troubleshooting

SimenB 에 2020년 04월 27일

ts-jest와 함께 isolatedModules: true 사용하면 콜드 스타트 업 (~ 10 분 => 15 초)에 큰 차이가 있음을 확인할 수 있습니다.
나는 jest 25로 업데이트하기 전에 # 9457이 해결되기를 기다리고 있기 때문에 알파에서 개선 사항을 테스트하지 않았습니다.

Cellule 에 2020년 04월 27일

안녕하세요,

여기에 같은 문제가 있고 해결책이 없습니다 ...

현재 몇 가지 테스트가있는 매우 간단한 코드를 실행합니다.
Wes Bo의 "Advanced React Course"에서 가져온 것입니다.
그는 Mac에서 실행하고 컴퓨터에서 즉각적인 답변을 얻습니다.

그리고 나를 위해 :

테스트 모음 : 2 건 건너 뛰고 15 건 통과, 총 17 건 중 15 건
테스트 : 6 건 건너 뛰기, 37 건 통과, 총 43 건
스냅 샷 : 18 개 통과, 총 18 개
시간 : 5.869 초
모든 테스트 스위트를 실행했습니다.

isolatedModules: true 내 경우에는 아무 것도 변경되지 않지만 여전히 5-6 초 정도입니다.
그리고 어떤 옵션으로 테스트를 시작하면 9 ~ 10 초 정도 걸립니다.

Defender Exceptions에 내 dev 폴더를 추가하면 아무것도하지 않았습니다.

테스트 모음 : 2 건 건너 뛰고 15 건 통과, 총 17 건 중 15 건
테스트 : 6 건 건너 뛰기, 37 건 통과, 총 43 건
스냅 샷 : 18 개 통과, 총 18 개
시간 : 5.563 초
모든 테스트 스위트를 실행했습니다.

Windows에 좋은 옵션이 있습니까?
wsl2로 가야하나요?

edriwing 에 2020년 04월 28일

안녕하세요,
여기에 같은 문제가 있고 해결책이 없습니다 ...
현재 몇 가지 테스트가있는 매우 간단한 코드를 실행합니다.
Wes Bo의 "Advanced React Course"에서 가져온 것입니다.
그는 Mac에서 실행하고 컴퓨터에서 즉각적인 답변을 얻습니다.
그리고 나를 위해 :
테스트 모음 : 2 건 건너 뛰고 15 건 통과, 총 17 건 중 15 건
테스트 : 6 건 건너 뛰기, 37 건 통과, 총 43 건
스냅 샷 : 18 개 통과, 총 18 개
시간 : 5.869 초
모든 테스트 스위트를 실행했습니다.
isolatedModules: true 내 경우에는 아무 것도 변경되지 않지만 여전히 5-6 초 정도입니다.
그리고 어떤 옵션으로 테스트를 시작하면 9 ~ 10 초 정도 걸립니다.
Defender Exceptions에 내 dev 폴더를 추가하면 아무것도하지 않았습니다.
테스트 모음 : 2 건 건너 뛰고 15 건 통과, 총 17 건 중 15 건
테스트 : 6 건 건너 뛰기, 37 건 통과, 총 43 건
스냅 샷 : 18 개 통과, 총 18 개
시간 : 5.563 초
모든 테스트 스위트를 실행했습니다.
Windows에 좋은 옵션이 있습니까?
wsl2로 가야하나요?

내 솔루션을 적용하고 어떤 일이 발생하는지 알려 주실 수 있습니까? (실제로 Cellule의 솔루션이지만 스크립트를 실행하는 대신 메뉴를 통해 수행했습니다)

alessioalex 에 2020년 04월 28일

내 솔루션을 적용하고 어떤 일이 발생하는지 알려 주실 수 있습니까? (실제로 Cellule의 솔루션이지만 스크립트를 실행하는 대신 메뉴를 통해 수행했습니다)

내 메시지에서 말했듯이 나는 이미 그것을했습니다 :)

메뉴를 통해 당신이 한 일을 따랐습니다.

edriwing 에 2020년 04월 28일

Windows에서도이 문제가 발생합니다. 테스트 자체는 1 초 미만으로 실행되지만 전체 설정은 실행하는 데 15 초 정도 걸립니다. v24 및 v26에서 시도했지만 실제로 v26에서는 조금 느립니다.

다음 중 하나에 운이 없었습니다 (실행 시간이 향상되지 않았습니다).

--runInBand
maxWorkers
@Cellule 및 @alessioalex가 제안한대로 Virus and Threat Protection .ts .js .spec.ts .spec.js .tsx 제외 추가

7hibault 에 2020년 06월 05일

👍1

바닐라 자바 스크립트와 새로운 타이프 스크립트 프로젝트와 함께 Windows에서 동일한 문제가 발생합니다. 모카를 사용하여 10ms 미만으로 실행되는 9 개의 단위 테스트를 실행하는 데 2 초가 걸립니다.

StevePavlin 에 2020년 06월 12일

미친 짓이야!

단순히 jest를 전 세계적으로 설치하면 이제 정확히 동일한 프로젝트가 52 (!!!) 초가 아닌 0.9 초에 실행됩니다!
프로젝트에 npm remove jest
npm install -g jest

물론 개발자 종속성으로 jest를 프로젝트에 다시 통합하고 싶습니다. 왜 그런지 아십니까?

JPustkuchen 에 2020년 08월 05일

👀4

미친 짓이야!
단순히 jest를 전 세계적으로 설치하면 이제 정확히 동일한 프로젝트가 52 (!!!) 초가 아닌 0.9 초에 실행됩니다!
프로젝트에 npm remove jest
npm install -g jest
물론 개발자 종속성으로 jest를 프로젝트에 다시 통합하고 싶습니다. 왜 그런지 아십니까?

이것은 나에게 바이러스 스캐너 문제처럼 들립니다. 즉, 프로젝트 디렉토리는 크롤링 속도를 늦추는 바이러스 스캔 범위에 있지만 글로벌 npm 디렉토리는 그렇지 않습니다. 이것은 단지 추측 일뿐입니다.

empperi 에 2020년 08월 05일

👍4

방금 @JPustkuchen 과 동일한 것을 시도했으며 성능은 ~ 10 초에서 1 초 미만으로 이동합니다.

josh-barker 에 2020년 08월 16일

Windows Defender에서 프로젝트 폴더를 제외했지만 Jest가 여전히 느리게 실행됩니다.

theantichris 에 2020년 08월 18일

아직 작업 중인지 모르겠지만 코드에서 오타를 입력하면 시계 모드의 테스트가 즉시 실패합니다. 테스트를 컴파일하기 전에 실제로 새 디렉토리 크롤링을 강요하지 않는다는 생각이 들었습니다. 아주 간단한 테스트에도 10 초가 걸립니다.

SimeonRolev 에 2020년 09월 23일

누군가가 적어도 이것이 문제라는 것을 인정하기를 바랍니다. 현재로서는 충분한 성능을 가진 내 Windows 데스크톱 컴퓨터 (동료 인 맥북보다 훨씬 더 많음)가 테스트를 실행할 때 맥북보다 약 69 배 느립니다! Jest 테스트가 너무 느리게 실행되기 때문에 작업하는 것이 너무 비효율적이므로 실제로 프런트 엔드 코드를 건드리지 않도록 강요합니다. 이 문제가 해결되지 않으면 Jest에서 멀어져 야 할 수도 있습니다. 다른 모든 것은 번개처럼 빠르지 만 Jest 테스트는 매우 느립니다. 실제 테스트 로직이 실행될 때 실제로 테스트를 실행하는 것 외에 다른 작업에 시간이 소요됩니다.

empperi 에 2020년 10월 02일

👍6

좀 더 긍정적 인 점에서, 저는이 버그에 감사의 큰 빚을 졌다고 말하고 싶습니다. 주요 개발 워크 플로우를 위해 Linux로 전환하기로 결정하게 된 것은 마지막 빨대였으며 그 어느 때보 다 행복했습니다. 가끔 레거시 프로젝트에서 작업해야하기 때문에 절대로 돌아 가지 않을 것이라고 말할 수는 없지만 ASP.NET 코어가 크로스 플랫폼이기 때문에 Windows로 다시 부팅하는 이유가 항상 줄어들고 있습니다.

timrobinson33 에 2020년 10월 02일

😄2 👎2 👍2 ❤1 😕1

@ timrobinson33 제발 주제에 대해 계속합시다. Node가 모든 플랫폼에서 잘 작동한다는 점을 고려하면 jest 이 Windows의 다른 환경보다 68 배 느려 야 할 이유는 없습니다. 또한 다른 테스트 러너에서는이 문제를 경험 한 적이 없습니다.

alessioalex 에 2020년 10월 02일

👍3

벤치 마크 jest github repo에서 v26.4.2로 테스트했습니다.
https://github.com/nasreddineskandrani/benchmark_jest
내 컴퓨터의 노드 버전 : v12.13.0

간단한 테스트를 업데이트해도 괜찮습니다 (스크린 샷 참조)! 나에게 농담은 이제 간단한 테스트에 맞습니다.
직장에서 문제가있는 경우. 기본적으로 괜찮 기 때문에 문제를 분리해야합니다.

@empperi 내 벤치 마크 저장소를 사용해 볼 수 있습니다. 예를 들어 v26 폴더로 컴퓨터에서이 테스트를 실행하는 데 걸리는 시간을 알려주세요. 0.166ms가 아니거나 주변에 문제가있는 것입니다.

nasreddineskandrani 에 2020년 10월 04일

👎2

벤치 마크 jest github repo에서 v26.4.2로 테스트했습니다.
https://github.com/nasreddineskandrani/benchmark_jest
내 컴퓨터의 노드 버전 : v12.13.0
간단한 테스트를 업데이트해도 괜찮습니다 (스크린 샷 참조)! 나에게 농담은 이제 간단한 테스트에 맞습니다.
직장에서 문제가있는 경우. 기본적으로 괜찮 기 때문에 문제를 분리해야합니다.
@empperi 내 벤치 마크 저장소를 사용해 볼 수 있습니다. 예를 들어 v26 폴더로 컴퓨터에서이 테스트를 실행하는 데 걸리는 시간을 알려주세요. 0.166ms가 아니거나 주변에 문제가있는 것입니다.

예상대로 테스트 설정 성능에는 차이가 없습니다. 실제로 컴퓨터보다 약간 빠르게 실행됩니다. __tests__ 아래에 100 개의 테스트 파일을 포함하도록 테스트 설정을 변경했으며이 파일도 정상적으로 실행됩니다. 우리 앱은 react-scripts 를 사용하기 때문에 실제 문제를 일으킬 수 있지만 성능에는 차이가 없는지 확인하기 위해 예제에 추가했습니다.

그러나 나는 WSL2 bash (NTFS 파일 시스템에 대해) 및 붐에서 이러한 테스트를 실행하려고 시도했으며 실행 시간은 원시 powershell에 비해 거의 10 배였습니다. NTFS에 대한 WSL2에서는 더 느린 I / O 속도가 예상되지만이 설정이 얼마나 간단한지를 고려하면 (각각 단일 테스트가있는 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가 I / O를 사용하는 방식에 문제가 발생했을 수 있으며 이는 WSL2의 성능에 크게 영향을 미칩니다. 나에게 문제를 일으키는 프로젝트에 관해서는 코드 및 테스트의 문제로 인해 bash를 요구하지 않는 것이 간단한 작업이 아닙니다. WSL2가 인기를 얻고 있다는 사실을 감안할 때 이것은 조사해야 할 실제 문제라고 말할 수 있습니다.

도움이 되었기를 바랍니다.

:편집하다:

호기심으로 나는 --no-watch 로 테스트 스위트를 실행하여 WSL2를 통해 파일 시스템을 보는 것이 어떤 영향을 미치는지 확인했습니다. 대답은 '아니오'입니다. 실제로 그다지 영향을주지 않습니다.

empperi 에 2020년 10월 05일

👍2 👀1

내 Windows 컴퓨터에서 벤치 마크를 실행하는 데 약 1.6 초가 걸립니다. WSL을 사용하지 않습니다.
AVG 바이러스 백신을 사용하고 있지만 리포지토리 및 노드 실행 파일에 대한 예외를 추가했습니다.
내 하드 드라이브는 SSD입니다.

노드 버전은 v12.16.1

테스트를 업데이트하면 파일 감시자가 즉시 트리거되지만 해당 업데이트를 실행하는 데 걸리는 실제 시간은 약 1 초 ~ 2.4 초입니다.

Glinkis 에 2020년 10월 05일

👀1 👍1

환경이 문제인지 테스트하고 싶었습니다.

이 저장소를 엉망으로 만들었습니다 .https : //github.com/kentcdodds/react-testing-library-course/tree/tjs

나는 npm test 가서 모든 테스트가 시계 모드에서 실행되기 시작합니다.
'p'를 눌러 파일 패턴을 입력하고 "tdd-02"를 입력합니다. 3 초 이상의 실행 시간을 얻습니다.

Kent C. Dodds가 유급 과정에서 엉망인 환경을 가지고 있다면 놀랄 것입니다. 그러나 그가 그렇게한다면 아마 거기에서 디버그 할 수 있습니다. :? 그의 비디오에서는 잘 작동하며 Mac을 사용하는 것 같습니다.

다시 재현 할 수없는 매우 이상한 점을 주목해야합니다. 파일 중 하나 (tdd-02 ... js)에 대해 약 0.1 초 동안 실행되고 그 옆에있는 파일 ( tdd-01 ... js)-약 3 초. 코드는 거의 동일하며 동일한 종속성을 사용합니다. 그래서 빠르게 실행되는 파일에서 코드를 복사하여 느리게 실행되는 파일에 붙여 넣거나 그 반대의 경우도 마찬가지입니다. 결과는 동일했습니다. 느리게 실행되는 파일은 느리게 유지되고 빠르게 실행되는 파일은 실제 코드가 바뀐 상태로 빠르게 유지되었습니다. 미쳐 가고 있습니다. 이제 두 파일이 다시 느리게 실행됩니다 (3-6 초).

SimeonRolev 에 2020년 10월 05일

👀1

@Glinkis 첫 번째 실행 후 Enter 키를 눌러도 될까요? 여전히 1.6 초 안에 표시 되나요? (재방송 트리거)

@SimeonRolev 나는 당신이 게시 한 예제를 살펴보고 동일한 단계 (패턴 ...)로 어떤 종류의 숫자를 얻었는지 볼 것입니다.
최신 정보:
try1 : 나는 당신의 단계를 시도했을 때 내가 그것을 시도하고 6 초를 얻었습니다-> 같은 테스트를 다시 실행할 때 3 초로 떨어졌습니다 (입력을 누르십시오)
try2 : Kent repo에서 jest를 26.4로 업그레이드-> 재실행을 위해 거의 동일하게 3 초 실행
try3 : 벤치 마크 테스트 저장소에서 index.spec.js 파일을 가져 왔습니다. 그리고 Kent repo에 떨어 뜨 렸습니다. (다른 모든 테스트 파일 삭제)-> 놀람 2.8 초 (SAME JEST 26.4.2, SAME COMPUTER, POWERSHELL, NODE_VERSION 등 ... 어제 테스트가 여기에 게시 됨)

나는이 try3을 여전히 이해하지 못합니다 => 내 파일에 대한 Kent repo 에서 재실행시 ~ 3sec이지만 내 repo 에서는 재실행시 0.300s로 떨어집니다 (이것을 디버깅해야합니다)
편집 : 켄트가 이것을 확인해야합니다 : P

nasreddineskandrani 에 2020년 10월 06일

👍3

Enter를 누르면 약 200ms 내에 테스트가 실행됩니다.

Glinkis 에 2020년 10월 06일

🚀1

@nasreddineskandrani 그 반대로 시도 했습니까? 내 말은, 느린 저장소에서 당신의 것으로 테스트를 복사하는 것입니까? 그러나 문제가 내가 게시 한 저장소에 있다고 생각하지 않습니다. 분명히 알 수 있듯이 많은 사람들이 동일한 문제를 겪고 있으며 재현 가능한 예를 게시했습니다.

@kentcdodds 한 번 더 우리의 영웅이 되시겠습니까?

SimeonRolev 에 2020년 10월 14일

@SimeonRolev 내 벤치 마크에서 Kent repo와 동일한 문제가 보이지 않습니다. Kent Repo에 뭔가 있습니다. 이 느린 원인은 => 외부 농담이 더 빠릅니다.

이 github 문제는 동일한 성능에 도달하지 않았기 때문에 Jest 성능 창과 macOS / Linux와 관련이 있습니다. 그들은 내 생각에 그것을 절하지 않았다. (jest v23을 사용하면 2 년 전보다 훨씬 나음)

nasreddineskandrani 에 2020년 10월 15일

안녕하세요, 여기에서도 같은 문제가 발생합니다. Windows 컴퓨터와 WSL이 있습니다. 이 동작을 테스트하기 위해 프로젝트 파일을 WSL에 복사했습니다. 다음은 동일한 두 가지 기본 테스트의 실행입니다.
Windows 10 (버전 2004) :

WSL 2 (Ubuntu 20.04) :

테스트는 매우 간단합니다.

프로젝트는 CRA로 생성되었으므로 설정을 망칠 수있는 구성이 없으며 Jest 측면에서 아무것도 추가하지 않았습니다.
동일한 테스트가 거의 즉각적으로 모카에서 엄청나게 빠르게 실행됩니다. 우리 프로젝트를위한 테스트 환경을 설정하려고하는데, Jest를 정말로 사용하고 싶지만, 점점 더 많은 테스트를 추가할수록 테스트 스위트가 느리고 느려질 것 같습니다. 각각의 테스트는 0.8 초를 추가하는 것 같습니다. Windows에서 테스트 실행을 엉망으로 만드는 것이 무엇인지 모르겠습니다.
문제는 더 심했다. 한 번의 테스트는 15 초 정도 걸리지 만 --runInBand와를 추가하면 상황이 조금 나아지는 것 같았지만 모카 워치 모드가 즉각적이라는 점을 감안할 때 여전히 충분하지 않다고 생각합니다.

Yarn은 버전 1.22.5이고 다른 모든 npm 종속성 (예 : react 및 react-scripts)은 최신 버전입니다.

바이러스 백신 및 Windows 방어기를 비활성화하여 효과가 있는지 확인했지만 그렇지 않습니다. 또한 내 프로젝트 폴더에 대한 인덱싱을 비활성화하여 아무 소용이 없습니다.

편집 : Enter 키를 눌러 보았고 테스트는 WSL만큼 빠릅니다.

이제 정말 혼란 스러워요 :)

그러나 이것은 여전히 매우 느린 것 같습니다. 각 테스트는 0.3 초가 걸리기 때문에 아무 작업도하지 않는다는 점을 감안할 때 매우 많습니다. 이 스위트는 0.1 초 이내에 완료 될 것으로 예상합니다.

편집 2 : 테스트 모음에 100 개의 테스트를 추가했을 때 Enter 키를 눌러 실행하더라도 실행하는 데 약 44 초가 걸렸습니다.

동일한 테스트 모음은 WSL에서 약 9-10 초가 걸립니다.

fatihdogmus 에 2020년 11월 11일

👍6 👀1

Jest: Jest는 모든 Windows 시스템 (Windows 10 이하)에서 3 배 느립니다.

🐛 버그 보고서

재현하려면

예상되는 행동

`npx envinfo --preset jest`

가장 유용한 댓글

모든 76 댓글

처음 1.7 초의 스크린 샷 :

1.8 초 ~ 2.7 초 스크린 샷

기록 후 ndb의 프로필 탭에서 저장된 .json 파일 및 .heapsnapshot 파일 :

관련 문제