Jest: 在所有Windows机器（Windows 10及更低版本）上，Jest的速度都要慢3倍

相关：＃6783

启动缓慢还是在监视模式下？ 如果仅在启动期间，则可以尝试安装watchman ，这应该会有所帮助（https://facebook.github.io/watchman/docs/install.html）

当它通过测试时，从头到尾看起来都不错（编辑：实际上，它在运行测试时也较慢。它以0.5秒的速度一一通过，而标准感觉是0.05
每次测试秒数）
但是，它在启动和/或启动玩笑测试时很慢（延迟约4-6秒，比Mac机器慢4-6倍）

我会请守望的人找你

如果您可以使用ndb的启动文件进行分析，并找出运行缓慢的地方，那也将是一个很大的帮助

即使安装了守卫，延迟仍然很慢。
我已经使用运行“ jest --verbose”的ndb运行了性能测试，结果如下：

前1.7秒的屏幕截图：

1.8秒至2.7秒的屏幕截图

录制后从ndb的配置文件选项卡中保存的.json文件和.heapsnapshot文件：

profiling.zip

@pfftdammitchris您注意到缓慢的[确切]用例是什么？
（一个文件或多个文件）？ （观看模式或否）？ 你能提供例子吗？
一个文件监视模式的问题=>请阅读我的最后评论：＃6783

无论有或没有监视模式，单个文件和多个文件的速度都很慢。 几乎每次运行任何测试时，初始化测试都会有3秒以上的延迟，并且每次运行测试的速度分别慢0.3、0.4或0.5秒，而其他慢跑者（如mocha / chai）通常只会运行每个感觉就像每个0.05秒。

我在codeandbox中使用jest，它们似乎在初始化/运行测试中立即运行jest，我看着我的同事在mac机上运行jest，然后像平常一样立即运行。 据我所知只是Windows机器。 我在工作中使用Windows机器，开玩笑说那里有慢速问题，在家里也使用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是Windows上所有问题场景下的Jest速度回归[v22 vs v23]。
   ＃6783是其中之一

2.我可以将此问题视为：对于所有有问题的场景，玩笑[Mac vs Windows]的速度问题。

大家好 ！
我累计开玩笑24和Windows 10的速度（400测试需要800秒！）。 我发现加快所有这些速度的更快方法是使用wsl而不是powershell或cmd。 现在我的测试仅需189秒。

我们有一套包含144个测试文件的1302个测试文件，这些文件在Windows 10 build 15063计算机（具有16GB的Core i7）上运行需要1分43秒，而在具有32GB的MAC OS Mojave上需要28秒。 我们的开发团队在Windows和Mac之间平均分配，并且这些数字非常可重复。

这是一个简单的测试-

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

我把它放在codesandbox，它运行几乎立即- https://codesandbox.io/s/4q8l0q52lw

在我的Windows计算机上，尽管需要4-5秒-

通过src / index.test.js
v作品（62ms）

测试套件：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
您可以在纱线分辨率中尝试使用micromatch 4吗？ 看看在Windows中是否更好？
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

我正在使用全新的MacBook Pro。 当我在MacOS和Windows 10上都有学生时，我决定在驱动器上再添加两个分区。 一个用于Windows 10，另一个用于使用Tuxera NTFS共享存储。

我今天在准备一个包含单元测试的JavaScript课程时遇到了这个速度问题。 我实际上是从MacOS运行Jest，但是代码和测试位于共享的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]，但是当以watch模式运行时，我仍然可以看到执行非常缓慢，任何帮助将不胜感激。

据我了解，@ 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"
  }
...

希望这可以帮助！ 等待反馈

我的测试运行时间也从23.6.0的约2.5分钟增加到24.7.1和24.8.0的约15分钟。 我们的CI服务器正在运行Windows，并且通过此升级，构建时间也出现了类似的大幅增长。 我已经尝试过@nasreddineskandrani上面提到的微

@TomMahle这是一个超级糟糕的新闻:(（我们上面讨论的回归已经在23.6中了）
现在，一个简单的“样本”项目确实表现出色。 微匹配更新后。
所以我们需要真正有问题的项目进行调试，您的项目是私有的吗？ 还是公开？

多谢您的建议micromatch @nasreddineskandrani，但像上面@TomMahle，将其固定到^4.0.0似乎没有任何改善我的表现。 😢

不过，我确实发现了一件时髦的事情，这可能有助于诊断此问题。

我可以在本地Windows系统上的docker容器中运行玩笑，而docker容器中的主要应用程序目录是从Windows文件系统挂载的。 在非监视模式下运行在两个系统中似乎具有几乎相同的行为，这可能暗示，正如@thebearingedge所暗示的那样，核心问题与NTFS文件系统有关，因为我的Docker容器最终将运行除文件系统中的所有文件系统一个Linux VM。

但是，在监视模式下，情况略有不同：本机窗口始终按预期运行缓慢，但是docker容器在第一次运行时仅运行缓慢p并输入模式），它就会在一秒钟之内很好地运行测试（在本机窗口中进行相同的操作需要3-4秒）。 使用docker的唯一缺点是文件更改事件似乎不会从我的Windows卷传播到docker，因此我必须手动按Enter来重新运行测试，而不是开玩笑地自动进行测试，但是我想这是与当前问题无关。

@nasreddineskandrani。 不幸的是我的项目是私人的。 如果有较小的代码示例（最好的配置？）或我可以提供的统计信息，我很乐意这样做。 所有测试似乎都非常慢（仅在Windows上），因此我认为这与特定测试无关。

我正在完成我为个人网站所做的docker工作->（一周后）我将再次讨论。

@汤姆马勒
我将尽我所能为您描述的问题提供一个repo github。

1. 您有几项测试？
2. 您是否为测试启用dom模式？
3. 是反应还是棱角？
   奖金：
4. 您可以尝试在github仓库中重现问题以进行调试吗？
   你可以分叉我的： https :
   要么
5. 也许在您的测试机上尝试我的存储库？ 看看结果吗？ 23.6至24之间

我认为Micromatch的维护者已经给予了足够的重视，因此必须已经解决了。 目前，在Windows上运行（因此编写）笑话测试是一种非常不愉快的体验。

从那时起我就搬到了摩卡（mocha）/柴（chai），但令我惊讶的是这个问题仍在研究中。

澄清度

我使用了--runInBand，但根据感觉，它似乎稍微降低了单元测试的速度，每一次又增加了0.2秒。

=>您尝试过v24吗？ 从v23到v24，仅在这种情况下您会看到一个很好的改进：
_在rerun加上watch并且仅当您针对一个文件运行时（而不是第一次运行时）_
-> 2/3秒降至0.4 / 0.5秒。
但与Mac相比，我从没尝试过...所以即使现在有所改进，它仍然很糟糕...

@SimenB

1. 我认为＃7110是Windows上所有问题场景的Jest速度回归[v22 vs v23]。
   ＃6783是其中之一

2.我可以将此问题视为：对于所有有问题的场景，玩笑[Mac vs Windows]的速度问题。

我在发布时尝试了这两个版本。

我刚刚用一个简单的数组推入测试创建了一个新项目，从开始到完成花费了10秒钟以上。 该项目正在使用react / typescript，但测试文件不是React组件文件，而是.js之类的普通文件。 如果可以更好地形象地查看问题的根源，请在下面提供Gif，以供直观参考：

我注意到，第一次运行测试时，它表明该测试估计为9秒。 完成后，它将第二次随机重试测试以完成测试。

当我在上面拍摄该gif图片（这是第二次）时，估计的时间减少了一点，并且没有执行第二次重试。 不知道这是否是预期的玩笑行为。

这是我在单独的项目中使用纱线运行micromatch 4的gif图像：

使用Windows 10和我的计算机规格为：
AMD FX（tm）-8320八核处理器3.50GHz
16GB内存
x64
固态硬盘

让我在这里分享我的分析。
眼镜：

• Windows 10专业版
• 节点10.15.3
• 英特尔酷睿i7-4702MQ 2.2GHz
• 8GB RAM
• x64
• 固态硬盘

脚步：

1. npx create-react-app my-app --typescript
2. 更改App.test.tsx
3. 运行npm test

CPU配置文件：

CPU-20190801T141211.zip

预计仅对单个琐碎的React组件和测试而言，仅需要用于重新包装模块的时间才花费15秒吗？

能在CPU分析方面有更多经验的人可以看看吗？

112个测试
窗户10
第一次运行507秒
第二次跑23秒
linux子系统
第一次跑步54秒
第二次跑29秒

85次测试
窗户10
第一次运行44秒
第二次跑15秒
Linux子系统
第一次运行26秒
第二次跑15秒

Kepro这些结果与micromatch 4有关吗？

我更喜欢直接聊天，而不是在这里拥有一百万条消息，要跟着与同一主题相关的所有问题进行交流真的是一个地狱。
您可以在这里加入。 https://gitter.im/wearefrontend/jest-slow-windows
我现在在...

Gitter被我公司的VPN阻止了-如果您可爱的人可以在这里发布任何有意义的更新，那将是令人惊讶的<3

您仍然可以在家连接以执行一些开源：P并检查它
ps一个dota游戏现在需要更多时间排队，现在您可以在这段时间内检查gitter；
这是现在的位置：nodejs / node＃28946

@nasreddineskandrani你得到了我。 我已经订购了一台新的Macbook，所以它将停止开源行动，直到它出现。 我拒绝在业余时间实际在糟糕的Windows盒上工作：D

看来问题已经转移到节点/ C ++领域，这在我的舒适范围之外（有点），但我还是会做一些探索！

嗨，有什么新闻吗？

作为解决方法，如果启动多个测试，则可以使用--runInBand。 开始第一个测试仍然需要很长时间，但是下一个测试将会很快。

我的项目执行所有测试花费了21.803s。
现在使用--runInBand仅需7.412秒

--runInBand对我来说变得更慢。 1200次测试。 没有runinBand 70/50秒。 使用--runInBand最多可在第二秒运行90秒
在Linux上，速度大约是5-8倍

然后尝试--maxWorkers = 4。

@ cino893 ，不是解决方案:)尝试查找修复方法，而不是解决方法

有什么消息吗？ 由于该错误，我使用了21版本。 v22慢，而v23甚至慢。
你们不是认为这是高优先级错误吗？

在我工作的地方，我们没有选择操作系统的自由，也没有在Window或类似工具上安装Ubuntu的自由。

@gombek您尝试过v25吗？ Jest团队全面提高了性能。

嗨，我只是想在此讨论中添加一些其他信息。 当在包含源代码和测试的Docker容器中执行时，Jest也非常慢，该容器通过主机系统（Windows）通过卷共享。

我可以肯定，这种放缓是由于Windows与Unix系统相比Windows处理文件句柄的方式有所不同。 在UNIX中，如果某个进程打开了一个文件句柄，但不会阻止其他进程读取该文件。 在Windows中，持有文件句柄的进程只要释放该句柄就拥有该文件。 我将研究用于文件读取逻辑的Jest代码，尤其是何时以及如何释放文件句柄。 行为良好的程序在完成工作后应该立即释放文件句柄。 无论如何，像Jest这样的测试运行者应该没有理由长时间保持文件句柄。

@gombek您尝试过v25吗？ Jest团队全面提高了性能。

我在Windows上使用Jest v25，但仍然很慢

@pfftdammitchris我已经在Mac + Windows上比较了相当复杂的测试套件，我看到了一些差异，主要是来自于冷缓存Windows明显慢一些，但是一旦变热，我就会在两者之间获得相似的性能。

然而...

在Windows上尤其要特别警惕的一件事是侵入性的内核级程序，例如Antiviruses / File-watcher，例如Carbon Black（或其他实时文件监视软件）。 如果您正在运行类似的程序，则在运行Jest时可以看到巨大的性能提升。 我说的是要花几十分钟才能运行测试。

去年，我在一家公司工作，在运行这些文件监视程序的情况下，同一测试套件在Macbook Pro上花费了大约30秒，在Windows笔记本电脑上花费了20分钟。

我不知道为什么，但我可能会猜测这与文件句柄以及Jest如何使用某些node.js文件系统API有关。

我只有大约20个测试，而且我只是在开玩笑地进行了一些计时--watch，无论是在初始运行还是在按Enter再次运行它们。

在Windows上，两次都花了大约15秒，而在Linux上，第一次运行大约是5.3秒，随后的运行大约是2.3秒。

我尝试使用-t =“ GARBAGE”导致跳过所有测试。 Linux花费了1.5秒，而Windows仍然花费了13秒，所以在我看来，花费时间不是测试的实际运行！

这两台机器都使用最新版本的node和jest，而linux实际上是使用hyper-v在Windows内运行的VM，因此在其他条件相同的情况下，我希望Windows会更快。

我只有大约20个测试，而且我只是在开玩笑地进行了一些计时--watch，无论是在初始运行还是在按Enter再次运行它们。

在Windows上，两次都花了大约15秒，而在Linux上，第一次运行大约是5.3秒，随后的运行大约是2.3秒。

我尝试使用-t =“ GARBAGE”导致跳过所有测试。 Linux花费了1.5秒，而Windows仍然花费了13秒，所以在我看来，花费时间不是测试的实际运行！

这两台机器都使用最新版本的node和jest，而linux实际上是使用hyper-v在Windows内运行的VM，因此在其他条件相同的情况下，我希望Windows会更快。

是。 而且，如果您将源代码从Windows挂载到linux VM并运行测试，它们的速度将与Windows中的速度一样慢。 这强烈表明问题出在我先前提到的Jest的文件处理逻辑中。

是。 而且，如果您将源代码从Windows挂载到linux VM并运行测试，它们的速度将与Windows中的速度一样慢。 这强烈表明问题出在我先前提到的Jest的文件处理逻辑中。

我注意到在测试运行期间，CPU很高，但磁盘使用率却不是。 这与阻止文件句柄有关，我希望它的CPU较低（除非开玩笑会在紧密的循环中等待句柄释放）

我看到了hevans90对文件查看器的评论。 我没有安装任何第三方防病毒软件或类似软件，但是禁用Windows内置的实时保护并没有明显的区别。

希望这对有时间尝试和调试它的人有所帮助。

因此，我今天确认Windows Defender发挥了巨大作用。
我曾经有很多例外，但是当我收到更新更快的笔记本电脑时，我无法终生搞清楚为什么开玩笑花了10分钟以上的时间来运行一个文件。

然后我想起了排除因素。
我无法确切地说出哪些排除措施会有所不同，但是我让跑步者下降到<15秒而不是> 10分钟

我发现了有相关排除的要点（尽管有力）
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
我还添加了文件扩展名.ts .js .spec.ts .spec.js .tsx

我无法确切地说出哪些排除措施会有所不同，但是我让跑步者下降到<15秒而不是> 10分钟

嗯，我只是试了一下，似乎对我没有任何影响（请注意，我没花几分钟，所以也许我们遇到了不同的问题）

无论如何，我总是有排除项。 实际上，IntelliJ Idea会自动建议将工作区目录放入排除范围，如果允许的话（您应该这样做）为您完成。 因此，在我的情况下，速度变慢不是由于Windows Defender或任何其他病毒扫描程序引起的。

与Mac相比，性能差异是5-10倍。 PC是一个功能强大的台式机（读：要快得多比MacBook）。 其他所有事情都快如闪电，只是Jest遭受了这个问题的困扰。

有任何更新吗？ 我遇到了同样的事情，每个测试都需要很长的时间来设置和加载，但是在第一个加载后，它以正常速度运行.....

也有这个问题。 具有单个hello world测试的单个测试文件，大约需要15秒钟才能启动，再加上12秒钟即可运行测试。

👋我看到一些回复暗示他们正在使用带笑话的打字稿-这可能值得研究（如果您还使用ts-jest）： https :

对我来说，变化是从等待30分钟的笑话（没有缓存）开始到几秒钟。

请记住，设置isolatedModules标志将不会对规范文件进行类型检查（并且不会丢失某些功能）： https :

我仅将其发布在这里，因为它可能对确定您的问题是否出于开玩笑很有帮助。

👋我看到一些回复暗示他们正在使用带笑话的打字稿-这可能值得研究（如果您还使用ts-jest）： kulshekhar / ts-jest＃908（评论）

对我来说，变化是从等待30分钟的笑话（没有缓存）开始到几秒钟。

请记住，设置isolatedModules标志将不会对规范文件进行类型检查（并且不会丢失某些功能）： https :

我仅将其发布在这里，因为它可能对确定您的问题是否出于开玩笑很有帮助。

纯JavaScript在这里。 我有这个问题，所以与TypeScript不相关。

仅供参考： https : https://github.com/kulshekhar/ts-jest/issues/1115的反馈

也有这个问题。 具有单个hello world测试的单个测试文件，大约需要15秒钟才能启动，再加上12秒钟即可运行测试。

只需在Mac上运行相同的测试即可。 启动大约需要1.5秒，运行测试需要1秒。

也使用JS，而不是TS。

这里也有Jest的纯JavaScript。 我有一台功能强大的四核笔记本电脑，带有英特尔的10gen处理器，其他所有功能都在快速发展，但是[email protected]在Windows和Linux上运行的基本测试所需的时间是Windows的2-3倍。

同样的问题，我的测试需要大约60秒才能在Windows上运行，并且在最初的45秒左右没有显示用户界面。 在我的Linux机器上运行了完全相同的测试套件，并且花了8秒钟才完成运行。

@Cellule的上面的评论大大加快了速度，使时间缩短了大约15秒。

@ryanrapini遵循了@Cellule的建议（但是经过了Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ），看到一些测试从13秒变为6，基本上是一半。 谢谢！

是否有人想在网站的“常见问题解答”页面上提供有关Windows Defender（通常是AV？）的部分？ https://jestjs.io/docs/zh-CN/疑难解答

我可以确认使用isolatedModules: true和ts-jest在冷启动时有很大的不同（〜10分钟=> 15秒）
我尚未测试其在Alpha中的改进，因为我在更新至笑话25之前等待解决＃9457

大家好，

同样的问题在这里，没有解决方案对我有用...

我运行了一些非常简单的代码，目前对其进行了一些测试。
它来自Wes Bo的“高级反应课程”。
他在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吗？

大家好，

同样的问题在这里，没有解决方案对我有用...

我运行了一些非常简单的代码，目前对其进行了一些测试。
它来自Wes Bo的“高级反应课程”。
他在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的解决方案，但我是通过菜单而不是运行脚本来完成的）

您能尝试应用我的解决方案并告诉我是否有帮助？ （实际上是Cellule的解决方案，但我是通过菜单而不是运行脚本来完成的）

正如我在消息中所说的，我已经做到了:)

我的意思是，我通过菜单和所有菜单都遵循了您的操作。

我在Windows上也遇到这个问题。 测试本身的运行时间少于1秒，但是整个设置大约需要15秒才能执行。 我已经在v24和v26上尝试过，但在v26上实际上要慢一些

我没有以下任何运气（它没有缩短执行时间）：

• 加--runInBand
• 设置maxWorkers
• 根据@Cellule和@alessioalex的建议，将.ts .js .spec.ts .spec.js .tsx排除项添加到Virus and Threat Protection

Windows上的相同问题，其中包含香草javascript和一个新的打字稿项目。 2秒钟运行9个单元测试，这些测试使用Mocha可以在<10ms内运行。

这太疯狂了！

只需在全球范围内简单地安装jest，现在完全相同的项目将在0.9s内运行，而不是52（!!!）秒！
npm remove jest在项目中，然后
npm install -g jest

当然，我想将玩笑作为开发依赖项再次集成到项目中。 知道为什么会这样吗？

这太疯狂了！

只需在全球范围内简单地安装jest，现在完全相同的项目将在0.9s内运行，而不是52（!!!）秒！
npm remove jest在项目中，然后
npm install -g jest

当然，我想将玩笑作为开发依赖项再次集成到项目中。 知道为什么会这样吗？

在我看来，这绝对像是病毒扫描程序问题。 意思是，您的项目目录属于病毒扫描范围，这会减缓进行爬网的速度，但不会影响您的全局npm目录。 不过，这只是一个猜测。

我刚刚尝试了与@JPustkuchen相同的〜10s变为<1秒。

我从Windows Defender中排除了我的项目文件夹，但Jest运行缓慢。

我不知道这是否仍在处理中，但是我注意到当我在代码中输入错误时，监视模式下的测试立即失败。 这使我想到，它实际上并没有在编译测试之前强制进行新的目录爬网。 对我来说，非常简单的测试也需要10秒钟。

我非常希望有人至少承认这是一个问题。 现在，我的Windows台式机具有强大的功能（阅读：比我的同事Macbook强大得多）在执行测试时比Macbook慢69倍！ 实际上，这迫使我不要触摸前端代码，因为由于Jest测试运行得如此缓慢，因此我无法高效地处理这些前端代码。 如果不能解决这个问题，我们可能不得不离开Jest。 其他一切都快如闪电，但笑话测试却慢于超级。 除了实际执行测试之外，还需要花费其他时间，而实际执行测试逻辑时，执行起来确实很快。

从更积极的角度来说，我只想说我欠这个bug很大的感谢。 这是最后的稻草，使我决定在主要的开发工作流程中改用Linux，而我从没有感到过快乐。 我不能说我永远都不会回去，因为有时我必须从事旧项目，但是由于ASP.NET核心是跨平台的，因此重新启动进入Windows的原因一直在减少。

请@ timrobinson33让我们继续关注话题。 考虑到Node在任何平台上都能正常工作，没有理由jest应该比Windows上任何其他环境慢68倍。 还可以补充一点，我没有遇到任何其他测试运行程序出现此问题的情况。

我在基准笑话github存储库中使用v26.4.2进行了测试。
https://github.com/nasreddineskandrani/benchmark_jest
我计算机上的节点版本：v12.13.0

当我更新简单测试时，效果很好（请参见屏幕截图）！ 对我来说，开玩笑现在对一个简单的测试是正确的。
如果您在工作中遇到问题。 您需要尝试找出问题，因为默认情况下很好。

@empperi ，您可以尝试我的基准存储库吗？ v26文件夹的示例，并告诉我在您的计算机上运行此测试需要多长时间？ 如果不是0.166ms或附近，则表示您的问题。

我在基准笑话github存储库中使用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倍。 预期在WSL2上针对NTFS的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观看文件系统是否会以某种方式影响事物。 答案是否定的，它的影响并不大。

在Windows计算机上运行基准测试大约需要1.6秒。 我没有使用WSL。
我正在使用AVG防病毒软件，但为存储库和节点可执行文件添加了例外。
我的硬盘驱动器是SSD。

节点版本为v12.16.1

更新测试会立即触发文件查看器，但是运行该更新的实际时间约为1s-2.4s。

我想测试环境是否是问题所在。

我在搞这个仓库： https :

• 我选择npm test ，所有测试开始在监视模式下运行。
• 我按“ p”输入文件格式，然后输入“ tdd-02”。 我得到3秒以上的执行时间。
  

如果肯特·C·多德斯（Kent C. Dodds）的收费课程有一个混乱的环境，我会感到惊讶，但是如果他这样做，您可以在那调试一下： 在他的视频中，它运行得很好，我认为他使用的是Mac。

我必须注意一些非常奇怪的东西，我无法再次复制-我对文件之一（tdd-02 ... js）执行了大约0.1s的连续测试重新运行，并对其旁边的文件进行了重新测试（ tdd-01 ... js）-大约3秒钟。 代码几乎相同，并使用相同的依赖项。 因此，我从运行速度很快的文件中复制了代码，并将其粘贴到运行缓慢的文件中，反之亦然。 结果是相同的-慢速运行的文件保持缓慢，快速运行的文件保持快速，并交换了实际的代码。 这太疯狂了。 现在，两个文件再次运行缓慢（3-6秒）。

@Glinkis可以在第一次运行后尝试按Enter还是显示1.6秒吗？ （触发重新运行）

@SimeonRolev我将看一下您发布的示例，看看我用相同的步骤得到什么样的数字（模式...）
更新：
try1：我以u的身份尝试它，并在尝试您的步骤时得到了6秒->重新运行相同的测试时下降到3秒（按Enter）
try2：将肯特仓库中的笑话升级到26.4-> 3秒，第一次重跑几乎相同
try3：我从基准测试存储库中提取了index.spec.js文件。 然后我把它丢给了肯特仓库。 （删除所有其他测试文件）->令人惊讶的2.8秒（SAME JEST 26.4.2，SAME COMPUTER，POWERSHELL，NODE_VERSION等...昨天在我的测试中发布）

我不明白try3仍然=>〜3秒，在Kent repo中重新运行我的文件，但是在我的repo中，它在重新运行时下降到0.300s （需要有人调试）
编辑：肯特应该是检查此：P的人

按Enter键可使测试运行约200毫秒。

@nasreddineskandrani反之亦然吗？ 我的意思是，将测试从慢速仓库复制到您的实验室吗？ 但我认为问题不在于我发布的回购。 我们可以清楚地看到，很多人都遇到同样的问题，我只是发布了一个可复制的示例。

@kentcdodds您还会再一次成为我们的英雄吗？

@SimeonRolev在我的基准测试中，我看不到与Kent回购中相同的问题。 您在Kent Repo中有东西。 导致此慢=>在外面玩笑会更快。

这个github问题与Jest性能窗口与macOS / Linux有关，因为它们没有达到相同的性能。 他们没有条款我猜。 （与jest v23相比，它现在比2年前要好得多）

您好，我在这里遇到同样的问题。 我有Windows机器和WSL。 我将项目文件复制到WSL以测试此行为。 这是两个相同的基本测试的运行：
Windows 10（2004版）：

WSL 2（乌汶图20.04）：

测试非常简单：

该项目是使用CRA创建的，因此没有可破坏设置的配置，就Jest而言，我没有添加任何内容。
相同的测试几乎可以立即在Mocha上快速运行。 我正在尝试为我们的项目设置测试环境，并且我真的很想使用Jest，但是随着我添加越来越多的测试，测试套件的速度似乎越来越慢。 每个测试似乎都增加了0.8秒，这很荒谬，因为它们什么也不做。 Windows上的测试执行有些混乱，我不知道是什么。
问题更严重，单个测试大约需要15秒，但是当我添加--runInBand和时，情况似乎有所改善，但是考虑到摩卡手表模式是即时的，我认为这还不够。

Yarn是1.22.5版本，所有其他npm依赖项（例如react和react-scripts）都是最新的。

我禁用了防病毒和Windows Defender，以查看它是否有效果，但没有效果。 另外，我禁用了对我的项目文件夹的索引编制，但均无济于事。

编辑：我尝试按Enter键，并且测试与在WSL上一样快：

现在我真的很困惑:)

但这似乎仍然很慢，因为考虑到它们什么也不做，因此每次测试似乎需要0.3秒，这是很多时间。 我希望此套件能在0.1秒内完成。

编辑2：当我在测试套件中添加了100个测试时，即使按回车键来运行它们也要花大约44秒钟来运行它们：

在WSL上，相同的测试套件大约需要9-10秒：