这是一个关于 Jest 在 JS 服务端的经验分享，注意，不是 UI 测试。如果你对 Jest 感到满意，请不要切换！这不是为了说服任何人。
Jest 是个众所周知的、功能完备的测试框架，曾经在选择时并没有经过深思熟虑。然而，经过数百次测试后，情况开始变得很糟糕。内存泄漏开始浮出水面，临时的标志位数量增多，经常访问 Jest 的 issues 标签页已经成为家常便饭。
以下是作者曾在 Jest 中遇到的一些问题，通过这些标志可以帮助排插问题或提高部分的性能，如果你在使用 Jest，可以做为一个参考。
jest —logHeapUsage：监视堆使内存用情况，以发现突然增长的内存泄漏。jest —maxWorkers=50%：一些基准测试显示，该配置可使测试运行速度提高 20%，也有些人说这会变得更糟。jest —runInBand: 这在当前进程中串行运行所有测试，而不是创建一个子进程的工作池。有人说这对于调试很有用，但奇怪的是，一些人报告说它实际上可以提高性能。jest —changedSince：该标志可以显著减少 PR 工作流程所需的时间。jest-slow-test-reporter：这个报告器可以发现你项目中最慢的测试。--expose-gc：暴露 Node.js 的垃圾收集器。某些情况下，使用 --expose-gc 标志运行 Node 似乎能更好地处理内存泄漏。这些策略中的一些在这段时间内显著减少了运行时间。然而，学习和实施它们的过程是以交付时间为代价的，而这实际上更为关键。
测试是如此缓慢，以至于我只在我们当前正在开发的模块上运行它们，然后只在PR中更改的模块上运行它们，最后，所有的测试只有在合并到主分支时才会运行。不幸的是，这种方法导致了识别错误的延迟。
测试如此耗时，以至于我发现自己在为某些功能犹豫是否编写测试，担心它们会导致额外的构建过程时间。在这一点上，我意识到是时候转变了
我十年前用过 Mocha，感觉非常棒。所以，我以为回到 Mocha 会很顺利。在过去的几年里，我看到人们一直在抛弃从 Jest 到 Mocha 的想法，而我总是觉得很有趣。我记得有很多指南和人们在谈论从 Mocha 迁移到 Jest。像我一样，大多数人会认为更新的工具会有更好或者至少类似的性能。
迁移比预期的要容易得多。几个替换案例，少于一个小时的重构一些代码。比较困难的部分是模拟引擎，这在 Mocha 中没有包含。
我本来可以使用 Sinon.js 来做到这一点，但我真的很喜欢有一天不依赖任何测试库的想法。我甚至考虑过只使用新的 Node.js 内置测试运行器，但对我来说它还不够完善。所以，我决定只使用内置的 MockTracker。
尝试后让人惊讶。使用 Jest 运行需要3秒的单个测试，在 Mocha 中只需要不到 200ms。这应该不足为奇——我运行的测试不应该花费那么长时间，但我已经习惯了那种缓慢。最终，我们的测试运行时间从超过 12 分钟缩短到不到 40 秒。
Mocha 的速度帮助我们发现了隐藏的错误，这些错误偶尔会导致测试失败，因为它们只在非常特殊的条件下发生——这些条件在 Jest 中由于其较慢
我仍然在我维护的一些较小的代码库中使用 Jest，并且除非它们成为问题，否则我不会疯狂地迁移它们。然而，对于未来的项目，我肯定会选择 Mocha 或 Node.js 测试运行器。
问题在于，即使有一种方法可以优化 Jest 并在合理的时间内运行数千个测试，但仅仅切换测试框架就能显著提高性能，这是有问题的。你同意吗？你有类似的经历吗？我很乐意听听。
作者 | Patrickrbc翻译、整理 | 五月君原文 https://patrickrbc.com/2024/03/16/jest-slow-tests
本文链接：http://www.28at.com/showinfo-26-79988-0.html放弃 Jest 后，运行时间减少 90%！
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 球盒模型：一切回溯穷举，皆从此法出
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号