本文详解在 react native 中使用 react native testing library 进行组件单元测试时，为何必须对 redux、asyncstorage、firebase messaging 等外部依赖进行模拟，并提供可直接复用的 mock 配置方案与常见错误（如 messaging is not a function）的精准修复方法。
本文详解在 react native 中使用 react native testing library 进行组件单元测试时，为何必须对 redux、asyncstorage、firebase messaging 等外部依赖进行模拟，并提供可直接复用的 mock 配置方案与常见错误（如 messaging is not a function）的精准修复方法。
在 React Native 单元测试中，“只测组件行为，不测依赖实现”是核心原则。当你调用 render(
- ❌ 因原生模块未加载而崩溃（如 Firebase、DeviceInfo）；
- ❌ 触发真实网络/存储 I/O，导致测试不可靠、变慢甚至失败；
- ❌ 使测试耦合于第三方服务状态，丧失单元测试的隔离性与可重复性。
因此，mock 不是“可选项”，而是强制要求——它确保测试仅验证组件自身的渲染逻辑、事件响应与状态流转。
正确模拟 Firebase Messaging 的关键：匹配导出方式
你遇到的 TypeError: (0 , _messaging.default) is not a function 错误，根本原因在于 mock 的导出结构与实际模块不一致。@react-native-firebase/messaging 是一个 ESM 默认导出函数（即 export default messaging()），但你当前的 mock 返回的是一个对象字面量，导致调用 messaging() 时抛出 TypeError。
✅ 正确写法需满足两点：
- 使用 __esModule: true 声明兼容 ES 模块；
- default 必须是一个可调用函数（而非对象），其返回值才可链式调用 .getInitialNotification() 等方法。
// __mocks__/@react-native-firebase/messaging.ts 或 test setup 文件中
jest.mock('@react-native-firebase/messaging', () => ({
__esModule: true,
default: jest.fn(() => ({
getToken: jest.fn(() => Promise.resolve('test-token')),
onMessage: jest.fn(),
onNotificationOpenedApp: jest.fn(),
getInitialNotification: jest.fn(() => Promise.resolve(null)),
// ⚠️ 注意：此处必须返回 Promise.resolve(...)，否则链式调用会报错
})),
}));
? 更健壮的做法是统一在 setupFilesAfterEnv（如 jest.setup.ts）中集中 mock，并为所有 Firebase 方法预设默认 resolve 值，避免每个测试重复配置。
其他高频依赖的标准 mock 模式
| 依赖库 | 推荐 mock 方式 | 关键说明 |
|---|---|---|
| @react-native-async-storage/async-storage | 使用官方 mock： jest.mock('@react-native-async-storage/async-storage', () => require('@react-native-async-storage/async-storage/jest/async-storage-mock')); |
✅ 开箱即用，完全模拟 AsyncStorage API 行为 |
| @react-navigation/native | Mock hooks 返回可控值： jest.mock('@react-navigation/native', () => ({ useNavigation: jest.fn(), useRoute: jest.fn(() => ({ params: {} })), useIsFocused: jest.fn(() => true), })); |
? useNavigation 返回空对象即可；useRoute 建议注入 params 防止 undefined 报错 |
| react-native-device-info | 显式返回 Promise： jest.mock('react-native-device-info', () => ({ getDeviceName: jest.fn(() => Promise.resolve('Test Device')), getUniqueId: jest.fn(() => Promise.resolve('test-id')), })); |
? 所有方法必须返回 Promise.resolve(...)，否则组件内 await 会挂起 |
最佳实践建议
- 优先使用 __mocks__ 目录：在项目根目录创建 __mocks__ 文件夹，按包名存放 mock（如 __mocks__/@react-native-firebase/messaging.ts），Jest 会自动优先加载，无需手动 jest.mock()。
- 避免在测试用例内 mock：将 mock 提升至 beforeAll 或全局 setup，保证一致性，防止漏 mock 导致偶发失败。
-
为副作用逻辑编写集成测试：若 checkIfAppOpenedByNotification 逻辑复杂，可在 mock 基础上补充行为断言，例如：
it('calls getInitialNotification on mount', async () => { const { unmount } = render(<loginscreen></loginscreen>); await waitFor(() => expect(messaging().getInitialNotification).toHaveBeenCalled()); unmount(); }); - 启用 resetModules：在 jest.config.js 中添加 "resetModules": true，确保每个测试用例获得干净的模块缓存，避免 mock 泄漏。
单元测试的价值，在于快速、稳定、可预测地守护组件契约。正确的依赖模拟不是繁琐负担，而是构建可靠测试金字塔的基石。从今天起，把 jest.mock() 视为 import 的必要搭档——它不掩盖问题，而是让问题暴露得更纯粹、解决得更精准。
