这是一个关于 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
上一篇: 球盒模型:一切回溯穷举,皆从此法出