在 react native 单元测试中，必须对 asyncstorage、firebase messaging、redux 等外部依赖进行精准 mock，否则测试会因真实副作用（如网络调用、原生模块初始化）而失败；本文详解为何要 mock、如何正确 mock，并提供可直接复用的配置方案。
在 react native 单元测试中，必须对 asyncstorage、firebase messaging、redux 等外部依赖进行精准 mock，否则测试会因真实副作用（如网络调用、原生模块初始化）而失败；本文详解为何要 mock、如何正确 mock，并提供可直接复用的配置方案。
在 React Native 应用的单元测试中，react-native-testing-library（RNTL）是推荐的组件渲染与交互测试工具。但一个常见误区是：仅渲染组件就足够了。实际上，只要组件内部使用了任何“非纯 JavaScript 逻辑”的依赖（如原生模块、异步持久化、状态管理中间件），测试运行时就会尝试加载真实实现——而这往往导致 TypeError、undefined is not a function 或挂起等待 Promise，正如你在 messaging() 调用处遇到的报错。
❓ 为什么必须 Mock？核心原则：隔离性（Isolation）
单元测试的目标是验证单个组件的行为，而非整个应用栈。若不 Mock：
- @react-native-async-storage/async-storage 会尝试访问原生桥接器（iOS/Android），测试环境无此能力；
- @react-native-firebase/messaging 在初始化时会触发原生 SDK 加载，Node.js 环境下必然失败；
- Redux store 若未注入或未 mock，useSelector/useDispatch 可能抛出 Invalid hook call；
- @react-navigation/native 的 useNavigation 等 Hook 依赖 Navigator 上下文，直连渲染会报错。
因此，Mock 不是“多此一举”，而是强制将被测组件与其外部世界解耦的必要手段。
✅ 正确 Mock 的关键：匹配导入路径 + 符合导出签名
你原始的 Firebase Messaging Mock 存在两个典型问题：
- 路径不精确：jest.mock('@react-native-firebase/messaging') 可能因模块解析顺序失效；
- 导出结构错误：RNFirebase vX+ 使用 default 导出一个函数（messaging()），但你的 Mock 返回的是一个对象字面量，导致 messaging() 调用时返回 undefined，进而报 TypeError: (0 , _messaging.default) is not a function。
✅ 正确写法（适配 RNFirebase v14+）：
// __mocks__/@react-native-firebase/messaging.ts 或 test setup file
jest.mock('@react-native-firebase/messaging', () => {
return {
__esModule: true,
default: jest.fn().mockReturnValue({
getToken: jest.fn().mockResolvedValue('mocked-token'),
onMessage: jest.fn(),
onNotificationOpenedApp: jest.fn(),
getInitialNotification: jest.fn().mockResolvedValue(null),
// 添加所有 LoginScreen 中实际调用的方法
}),
};
});? 提示：使用 jest.fn().mockReturnValue({...}) 确保 messaging() 调用返回一个模拟对象，而非直接返回对象（后者会使 messaging() 本身不可调用）。
? 完整可复用的 Mock 配置（推荐放入 setupTests.ts）
// setupTests.ts
import '@testing-library/jest-native/extend-expect';
import 'react-native-gesture-handler/jestSetup';
// Mock AsyncStorage（官方推荐方式）
jest.mock('@react-native-async-storage/async-storage', () =>
require('@react-native-async-storage/async-storage/jest/async-storage-mock'),
);
// Mock React Navigation（精简版，按需扩展）
jest.mock('@react-navigation/native', () => ({
useNavigation: jest.fn(),
useRoute: jest.fn().mockReturnValue({ params: {} }),
useIsFocused: jest.fn().mockReturnValue(true),
useFocusEffect: jest.fn((cb) => cb()),
}));
// Mock Firebase Messaging（修复 TypeError 的关键）
jest.mock('@react-native-firebase/messaging', () => {
const mockMessaging = jest.fn().mockReturnValue({
getToken: jest.fn().mockResolvedValue('test-token'),
onMessage: jest.fn(),
onNotificationOpenedApp: jest.fn(),
getInitialNotification: jest.fn().mockResolvedValue(null),
onNotification: jest.fn(),
});
return {
__esModule: true,
default: mockMessaging,
};
});
// Mock Device Info
jest.mock('react-native-device-info', () => ({
getDeviceName: jest.fn().mockResolvedValue('TestDevice'),
getDeviceId: jest.fn().mockResolvedValue('test-device-id'),
}));
// Mock Redux（若使用 @reduxjs/toolkit）
jest.mock('react-redux', () => ({
...jest.requireActual('react-redux'),
useSelector: jest.fn(),
useDispatch: jest.fn(),
}));并在 jest.config.js 中确保加载：
module.exports = {
setupFilesAfterEnv: ['<rootDir>/setupTests.ts'],
// ...其他配置
};⚠️ 注意事项与最佳实践
- 避免全局污染：不要在 describe 内部 jest.mock() —— 它必须在模块顶层执行（Jest 会自动 hoist），否则可能无效；
- 按需 Mock，而非全量：只 Mock 组件实际调用的方法（如 getInitialNotification），未使用的方法无需定义，减少维护负担；
- 类型安全建议：在 TypeScript 项目中，为 Mock 添加类型声明（如 declare module '@react-native-firebase/messaging'），避免 any 类型警告；
- 调试技巧：在测试中临时添加 console.log(messaging) 查看其实际类型，确认是否为函数；
- CI 友好性：确保所有 Mock 均不依赖真实设备或网络，保障测试在任意 CI 环境稳定通过。
✅ 总结
正确的 Mock 不是绕过问题，而是践行单元测试的黄金法则：控制变量，聚焦验证。当你看到 TypeError: (0 , _messaging.default) is not a function，第一反应不应是“怎么修报错”，而应是“这个依赖是否被正确隔离？它的调用契约是否被精准模拟？”——掌握这一思维，你将从 React Native 测试新手，进阶为可构建高可靠性移动应用的质量守护者。
