企业官网建设流程全解析

• 文档
• 教程
• 知识库

在 TIL 仓库的 JavaScript 测试笔记中，关于 Jest 有一条非常实用的技巧：当测试输出过于嘈杂，或者某个测试无意中依赖了另一个测试的执行顺序时，可以借助test.only()让 Jest 只运行你关心的那一个test块。读完本文，你将掌握test.only()的最简改法、它解决的两类典型问题（console 调试去噪与测试间依赖排查），以及它在整个 Jest 调试工具箱中的定位与配套技巧。

什么时候需要让 Jest "只跑一个测试"

日常开发中我们很少会遇到"全量测试"是理想工作流的情形，以下两类场景尤其适合引入聚焦运行：

• 测试输出嘈杂：一次跑几十上百个用例，console.log、断言结果、覆盖率信息混在一起，真正想看的结论被淹没。
• 测试间存在意外依赖：某个测试能通过，仅仅是因为它恰好运行在另一个测试之后，前者的副作用（全局状态、Mock、定时器等）被后者隐式复用。此时需要把可疑用例单独拎出来运行，验证它脱离上下文后是否依然成立。

此外，在写新用例、重构被测函数、或者对某个失败用例反复尝试修复时，全量跑一遍显然低效。这些都是把 Jest 的焦点收敛到某一个test块上的充分理由。

test.only()：五字符的精准聚焦

Jest 为test()提供了only修饰变体，用法是直接调用test.only()而不是test()。所谓"五字符的加法"，指的就是在test后追加的.only这 5 个字符（点号加 4 个字母）。

操作步骤很简单：找到你感兴趣的那个测试块，把test(改成test.only(，形如：

// tests above ... test.only('ensure the function returns the value', () => { // ... // test implementation // ... }) // tests below ...

加上这 5 个字符之后，Jest 只会运行这一个测试，跳过文件中其余所有测试。原文中的注释// tests above ...与// tests below ...意在强调：无论这个test.only位于文件中的哪个位置（开头、中间还是末尾），其余用例都会被跳过，聚焦逻辑与被聚焦用例的物理位置无关。

有一点可以放心：test与it在 Jest 中是互为别名的同一 API，因此it.only()与test.only()完全等效；类似的only修饰思路同样适用于describe块（describe.only()），当需要聚焦"一整组相关的用例"时，可以先把聚焦粒度放到describe层，再在组内继续收敛到单个test。

聚焦运行的核心价值：console.log 调试去噪

聚焦运行最典型的用武之地是调试场景。当你在测试代码里塞进若干console.log来观察中间值（这是 TIL 仓库中常见的排查手段，比如 pretty-print-some-dom-to-debug-a-test 一类的思路）时，全量跑会面临一个尴尬问题：你很难分辨当前这行日志到底是哪个测试打印出来的。

多个测试同时输出，日志相互穿插，即使打印了标识也不容易对号入座。而只运行一个测试，输出源就只剩一个，任何一行日志都可以确定性地归因到当前被聚焦的用例上，调试干扰被降到最低。

如果日志噪音本身来自被测代码抛出的报错信息（例如故意测试一个缺少必需 prop 的组件，从而触发 PropTypes 警告刷屏），TIL 仓库里还有另一条配套技巧——在 turn-off-console-error-messages-in-a-test 中，通过临时把console.error替换为jest.fn()再在用例结束时还原，即可让测试输出保持干净。聚焦运行与临时静默两者配合，基本可以覆盖"调试期间让输出可控"的全部需求。

聚焦运行的另一价值：隔离测试间依赖

除了去噪，聚焦还有一个更严肃的用途——验证并排查测试之间的意外耦合。当一个用例单独运行时失败、在全量运行时却通过，几乎可以断定它隐式依赖了其他用例留下的状态。

把可疑用例改成test.only()单独执行，就是最直接的隔离实验：

• 单独运行仍通过 → 说明该用例本身自洽，之前的"时好时坏"需要另找原因（例如并发、时序）。
• 单独运行失败 → 印证了它依赖其他用例的副作用，接下来就可以逐个排查它读取了哪些全局可变状态、哪些 Mock 没有在beforeEach中重置。

这种"先聚焦、再归因"的做法，比在全量输出里逐条比对日志高效得多。配合仓库中 test-timing-based-code-with-jest-fake-timers 提到的jest.useFakeTimers()与jest.advanceTimersByTime()，你可以把异步、定时器类的耦合用例也纳入同样的隔离验证流程。

用完之后记得收手：聚焦是手段，不是终点

test.only()是开发期的调试利器，但它的副作用是"跳过其余所有测试"。因此在使用时有两条基本纪律：

• 定位完问题后立即还原为普通的test()，避免下次运行在不知情的情况下只验证了一小部分用例，产生"测试全绿"的错觉。
• 留意是否会被误提交。一旦test.only()被提交进代码库并进入 CI，流水线上相当于只跑了一个用例，回归防护形同虚设。建议在提交前自查，或让审查者重点关注.only的出现。

把聚焦作为一种临时工作状态而非持久配置，才能既享受它的效率，又不牺牲全量测试的保障。

延伸：Jest 调试与测试控制工具箱

test.only()是 Jest 测试控制能力中的一环。在这个 TIL 仓库的 JavaScript 分类下，还沉淀了多条与之互补的 Jest 实战笔记，可在日常调试中组合使用：

• test-coverage-stats-with-jest：通过jest --coverage了解测试对代码的覆盖情况，判断聚焦调试后的用例是否覆盖了关键分支。
• mock-a-function-with-return-values-using-jest：用jest.fn()与mockReturnValue()/mockReturnValueOnce()控制被测函数的返回值，与聚焦运行搭配可精准复现"依赖某个返回值"的失败场景。
• define-a-custom-jest-matcher 与 support-nested-matching-in-custom-jest-matchers：通过expect.extend()定义贴合业务语义的断言，让被聚焦用例的断言更聚焦、更易读。
• turn-off-console-error-messages-in-a-test：临时静默console.error，与test.only()一起使用可以让调试输出干净到只有你想看的内容。
• configure-jest-to-run-a-test-setup-file：用setupTestFrameworkScriptFile（或较新版本的setupFilesAfterEach同类配置）统一配置测试框架，减少每个用例文件里的重复初始化，也让聚焦运行时的环境保持一致。

小结

test.only()是 Jest 提供的一个成本极低、收益直接的控制开关：把test(改成test.only(，仅 5 个字符，就能让 Jest 跳过其余所有用例、只运行你指定的那一个。它在两类场景中尤其有价值——console.log 调试时的输出归因，以及排查测试间意外依赖时的隔离验证。它应当被当作开发期的临时手段，定位问题后及时还原，避免把"只跑一个测试"的状态带入日常测试与 CI。掌握了它，再配合仓库中其他 Jest 笔记里的 Mock、静默输出与覆盖率技巧，你对测试过程的掌控力会明显提升。

• 文档
• 教程
• 知识库