我读到 --runInBand 标志在 CI 服务器上将 Jest 测试持续时间加快了 50%。除了它允许测试在同一个线程中按顺序运行之外，我真的无法在网上找到关于该标志的作用的解释。
为什么在同一个线程中运行测试并按顺序运行会使其更快？直觉上，这不应该让它变慢吗？
一些用户在阅读您的链接页面和其他一些相关来源（如 this github issue）后发现：
...使用 --runInBand 有助于资源有限的环境。
和
... --runInBand 将我们的测试从 >1.5 小时（实际上我不知道多长时间，因为 Jenkins 在 1.5 小时超时）缩短到 4 分钟左右。 （注意：我们的构建服务器资源真的很差）
正如我们所看到的，这些用户在他们的机器上的性能有所提高，即使他们的资源有限。如果我们从 docs 中读取 --runInBand 标志的作用，它会说：
别名：-i。在当前进程中连续运行所有测试，而不是创建运行测试的子进程的工作池。这对于调试很有用。
因此，考虑到这些评论和文档，我相信性能的提高是由于现在该进程在单个线程中运行。这极大地帮助了资源有限的计算机，因为它不必花费内存和时间来处理和处理线程池中的多个线程，对于其有限的资源而言，这项任务可能被证明过于昂贵。
但是，我相信只有当您使用的机器资源有限时才会出现这种情况。如果您使用更“强大”的机器（即：多个内核、不错的 RAM、SSD 等），使用多个线程可能会比运行单个线程更好。
当您在多线程中运行测试时，jest 会为每个线程创建一个缓存。当您使用 --runInBand 运行时，jest 会为所有测试使用一个缓存存储。
我在运行 20 个相同的测试文件后发现了它，首先使用键 --runInBand，第一个测试需要 25 秒，接下来的相同测试每个需要 2-3 秒。
当我在没有 --runInBand 键的情况下运行测试时，每个相同的测试文件都会在 25 秒内执行。
--runInBand 是否有益？我们使用 jest --coverage --runInBand --no-cache 进行持续集成。
--ci 标志添加到 codeepic 的命令中。 jestjs.io/docs/en/cli#ci
--runInBand显着提高了性能 - 这不是最先进的计算机，但我不确定我是否会称之为有限资源计算机。对我来说为什么 runInBand 更快没有任何意义。--runInBand也可能会减慢运行速度，例如。如果您有许多测试套件，最好使用--maxWorkers或--maxParallel并将其设置为核心/线程数。在我们的 Jenkins CI（4 核，8Gb）中，我们使用--runInBand进行了 50 分钟的单元测试，在将其设置为--maxParallel=4后下降到 20 分钟。如果没有任何这些设置，它就会因内存不足 (OOM) 而消失，因为它产生了许多线程（这两种方法都阻止了）。