Jest clearAllMocks在beforeEach中未正确重置mock调用问题

核心原因拆解 #

1. 对jest.clearAllMocks的清理边界存在认知偏差 #

很多人默认配置beforeEach(jest.clearAllMocks)就能实现测试用例间的完全Mock隔离，实际上这个API的清理范围非常有限：

• 它仅会清空Jest生成的Mock函数的调用记录、实例绑定、临时返回值/临时实现，既不会重置jest.mock工厂定义的持久化Mock逻辑，也不会触碰业务代码自己定义的模块级变量、缓存状态，更不会中断未执行完成的异步逻辑。
• 它不会处理React组件的残留副作用：如果组件卸载不彻底，包裹在Promise链、定时器中的fetch调用会延迟触发，直接计入当前运行用例的Mock调用计数。

2. 模块级缓存导致用例运行结果依赖执行顺序 #

你提到的组件内调用组织API的自定义Hook是问题的核心触发点：
这类Hook普遍会在模块作用域定义缓存变量（比如let orgDataCache = null），首次加载时缓存为空，会额外发起一次fetch请求拉取组织数据写入缓存，后续再调用Hook时直接读取缓存，不会重复发起请求。

• 全量运行测试时，先执行的edit names用例已经完成了组织API请求、写好了缓存，等运行edit phone用例时，Hook直接命中缓存，不会触发那次额外的请求，总调用次数刚好是2次，符合你的断言。
• 当你用test.only单独运行edit phone用例时，前面的用例没有执行，缓存为空，组件挂载后Hook会额外发起一次组织API请求，总调用次数变成3次，自然和写死的断言冲突。
  这种场景下jest.clearAllMocks完全不生效，因为它根本感知不到业务代码里自定义的模块缓存变量。

3. 异步副作用时序波动加剧不稳定性 #

如果你的测试没有等待所有组件异步操作执行完成，或者没有配置测试库的自动组件清理：

• 上一个用例中未处理完的异步请求、定时器回调，会延迟到下一个用例执行阶段才触发，被计入下一个用例的Mock计数。
• 全量运行时可能因为执行时序的巧合，这些延迟调用刚好在clearAllMocks执行前就完成，不会污染计数；单独运行用例时执行时序变化，延迟调用就会落到当前用例的调用栈里，导致计数不符合预期。

修复方案 #

• 不要写依赖调用顺序的脆弱断言：放弃fetch.mock.calls[固定索引]这种写法，改用expect(fetch).toHaveBeenCalledWith(expect.objectContaining({/* 匹配目标请求的参数特征 */}))校验特定请求是否发起，不需要关心请求在调用栈的位置。
• 涉及模块级缓存的场景，在beforeEach中增加jest.resetModules()重置所有模块的缓存状态，配合动态导入的方式加载测试组件，保证每个用例拿到的都是无状态的全新模块，不依赖其他用例的执行结果。
• 确保测试环境开启组件自动清理，每个用例执行后自动卸载挂载的组件；所有和组件交互的异步操作都要用findBy*、waitFor等异步API等待执行完成，不要残留未处理的Promise跨用例执行。
• 每个用例的调用次数断言必须满足独立运行成立的要求，不要把其他用例的执行副作用作为断言成立的前提。

内容的提问来源于stack exchange，提问作者Phil Lucks