Mock子组件回调事件的核心目标是切断子组件真实行为，控制其触发时机与参数，从而专注验证父组件对回调的响应逻辑；最推荐方式是通过props传入jest.fn()创建的mock回调，并用expect断言调用情况。
在前端组件测试中，Mock 子组件回调事件的核心目标是：**切断子组件真实行为，控制其触发时机与参数，从而专注验证父组件对回调的响应逻辑**。不需要渲染真实子组件，也不依赖其内部实现，只需让“它调用了某个函数”这件事可预测、可断言。
用 props 传入的回调函数直接 Mock
这是最常见也最推荐的方式。只要子组件通过 prop 接收回调（如 onSubmit、onChange），测试时就传入一个 Jest mock 函数：
- 用
jest.fn()创建 mock 回调，挂载到父组件 props 中 - 触发子组件交互（如点击按钮、输入文字），实际调用的是这个 mock 函数
- 用
expect(mockFn).toHaveBeenCalledWith(...)断言是否被正确调用、参数是否符合预期
例如 React 中测试一个表单父组件：
它把 handleSubmit 作为 prop 传给 SubmitButton；测试时不用渲染 SubmitButton，直接模拟“按钮被点击后调用了 handleSubmit({ type: 'save' })”，然后检查父组件是否更新了状态或发出了请求。
用 Wrapper 或 TestRenderer 模拟子组件行为
当需要更精细控制子组件“怎么触发回调”（比如模拟不同条件下的多次调用），可用测试工具提供的包裹能力：
立即学习“前端免费学习笔记（深入）”；
- Vitest / Vue Test Utils：用
mount的shallow模式或global.components替换子组件为一个精简版，内部手动调用props.onSuccess() - React Testing Library：配合
@testing-library/react+jest.mock()对子组件模块做内联 mock，返回一个只执行回调的占位组件 - 避免渲染真实子组件，既快又稳定，还能绕过子组件自身的副作用（如 useEffect、API 调用）
拦截并重写子组件导出的事件发射方法
某些 UI 库组件（如 Ant Design、Element Plus）通过实例方法触发事件（如 this.$emit('change') 或 instance.emit('select')）。这时可在测试中：
- 用
jest.spyOn监听子组件原型上的 emit 方法，或拦截其构造后的实例方法 - 或在 mount 前，用
jest.mock替换整个子组件模块，导出一个带可控emit行为的类 - 关键不是“让它看起来像真的一样”，而是“让它按你写的规则触发回调”
不推荐：硬编码或依赖 DOM 事件冒泡去模拟
不要试图通过 fireEvent.click(screen.getByRole('button')) 强行触发子组件内部按钮——这等于测试了子组件本身，违背了单元测试“隔离被测单元”的原则。如果子组件没导出清晰的回调 prop，说明设计上已耦合过重，应优先推动重构，而不是在测试里补救。
真正有效的 Mock 不是掩盖问题，而是暴露接口契约是否清晰。只要子组件对外暴露了可被传入和调用的回调函数，Mock 就很简单；如果连回调都藏在内部、靠 ref 或全局事件通信，那该修的是组件设计，不是测试写法。
