Jest测试报错：期望mock函数调用次数≥1，实际为0

执行Jest测试时遇到报错：expect(jest.fn()).toHaveBeenCalled()，期望调用次数≥1，实际调用次数为0。测试代码如下：

test("DD cancel", async()=>{
  getC.mockResolvedValueOnce(autoCompleteResp);
  const {cont}= render(<DDS/>,{initialState: initialStateMock});
  await waitFor(()=>{
    expect(getC).toHaveBeenCalled();
  });
});

getC接口及相关mock在其他场景使用均无异常。

以下是针对性的排查方向：

• 确认组件是否触发了getC调用
  检查<DDS/>组件的逻辑：getC是在组件挂载时自动执行，还是需要特定交互（比如点击按钮、输入文本）才会触发？当前测试仅渲染了组件，未执行任何操作，如果接口调用依赖用户交互，自然不会触发。可以在浏览器中运行组件，验证挂载或特定操作下是否会调用该接口。

• 校验mock实例的一致性
  确保测试中mock的getC和组件中实际引用的是同一个函数实例：

  • 核对组件和测试文件中getC的导入路径是否完全一致（比如组件用import { getC } from '../api'，测试也要从相同路径导入并mock）。路径不一致会导致mock失效，组件仍调用原函数。
  • 可以在测试中添加console.log(getC)，在组件调用getC的位置也打印该函数，对比两者的引用是否相同。

• 检查初始状态对组件逻辑的影响
  initialStateMock可能改变了组件的行为：如果初始状态中已经存在getC要获取的数据，组件可能会跳过接口请求。打印initialStateMock的具体内容，确认是否满足组件调用getC的前置条件（比如某字段为空才会发起请求）。

• 排查waitFor的使用问题

  • 若组件永远不会调用getC，waitFor最终会超时失败。可以增加超时时间参数：waitFor(() => {...}, { timeout: 5000 })，同时在测试中打印getC.mock.calls，确认是否真的没有调用记录。
  • 验证autoCompleteResp的格式是否符合组件预期，虽然格式错误一般不会导致不调用接口，但可能影响后续逻辑，需排除该因素。

• 检查是否存在mock重置干扰
  确认测试文件中是否在beforeEach/afterEach等钩子中对getC执行了mockReset或mockRestore，导致mockResolvedValueOnce的设置被清空。可以在测试开始前打印getC.mock，确认mock状态干净且mockResolvedValueOnce已正确配置。

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