Jest报ReferenceError: React is not defined是因为未配置JSX解析,需在jest.config.js中设置testEnvironment: 'jsdom'并配置Babel transform。

Jest 不是“必须配一堆插件才能跑起来”的测试框架,它开箱即用,但直接写 test 就报错、mock 不生效、组件渲染空白——这些问题基本都出在环境配置或断言逻辑上。
为什么 jest 运行时报 ReferenceError: React is not defined
这是最常遇到的启动失败。Jest 默认不理解 JSX,也不自动加载 React。你没漏装依赖,只是没告诉 Jest “这个文件要用 React 解析”。
- 确保已安装
react、react-dom和@testing-library/react(不是必须,但比enzyme更轻量且官方推荐) - 在项目根目录添加
jest.config.js,至少包含:
module.exports = {
testEnvironment: 'jsdom',
transform: {
'^.+\\.(js|jsx|ts|tsx)$': 'babel-jest',
},
transformIgnorePatterns: ['node_modules/(?!@react-native|react-clone-referenced-element)'],
moduleNameMapper: {
'\\.(css|less|scss|sass)$': 'identity-obj-proxy',
},
};
其中 testEnvironment: 'jsdom' 是关键:它让 Jest 模拟浏览器 DOM 环境;transform 告诉 Jest 用 Babel 编译源码;moduleNameMapper 避免样式文件导致解析失败。
如何为纯函数写可靠测试 —— 别只测 expect(fn()).toBe(...)
函数测试的核心不是“能跑”,而是覆盖边界条件和副作用行为。比如一个加法函数 add(a, b),只测 add(1, 2) === 3 是不够的。
立即学习“Java免费学习笔记(深入)”;
- 必须覆盖
null、undefined、NaN、字符串数字混合等输入 - 如果函数内部调用了
console.warn或fetch,要用jest.mock拦截,否则测试会真实触发副作用 - 避免在测试里写重复逻辑(比如自己算一遍期望值),应把“正确性”交给业务逻辑本身验证
示例:测试一个防抖函数 debounce(fn, delay)
test('debounce calls fn only once after delay', () => {
const fn = jest.fn();
const debounced = debounce(fn, 100);
debounced();
debounced();
debounced();
expect(fn).not.toHaveBeenCalled(); // 立即调用时不执行
jest.advanceTimersByTime(100); // 快进时间
expect(fn).toHaveBeenCalledTimes(1);
});
注意:jest.useFakeTimers() 要提前在 beforeEach 中启用,否则 advanceTimersByTime 无效。
React 组件测试总渲染为空白?检查 render 的返回值和查询方式
@testing-library/react 的 render 返回的是一个对象,不是 DOM 节点。直接 console.log(container) 看到的是空 div,不代表组件没渲染 —— 它只是没挂载到真实 body。
- 不要用
container.querySelector手动查元素,优先用screen.getByText、getByRole等语义化查询 API - 异步组件(比如内部有
useEffect请求数据)必须配合await waitFor,不能靠setTimeout或act手动包裹 - 如果组件依赖 Context,需在
render时用wrapper包一层 Provider
示例:测试一个加载用户姓名的组件
test('displays user name when loaded', async () => {
render( );
expect(screen.getByText(/loading/i)).toBeInTheDocument();
await waitFor(() => {
expect(screen.getByText(/john doe/i)).toBeInTheDocument();
});
});
这里 waitFor 会自动重试,直到断言通过或超时,默认 1000ms。别忘了 mock fetch 或对应 API 调用,否则请求会发向真实后端或抛错。
Mock 外部模块时,jest.mock 放错位置会导致 mock 失效
jest.mock 必须放在文件顶部(import 之后、任何实际调用之前),且不能包裹在 test 或 beforeEach 中 —— 否则 Jest 无法在模块加载前完成替换。
- 动态 mock(比如每次返回不同值)用
mockImplementation,不是mockReturnValue - mock 一个默认导出的函数时,要写
jest.mock('./api', () => ({ default: jest.fn() })),而不是只 mock 对象属性 - 如果被 mock 的模块本身有副作用(如初始化全局变量),可能需要在
afterEach里用jest.clearAllMocks()重置
常见错误写法:
// ❌ 错误:mock 在 test 内部,无效
test('calls api', () => {
jest.mock('./api', () => ({ fetchUser: jest.fn() })); // 不起作用
// ...
});
// ✅ 正确:放在顶部
jest.mock('./api', () => ({
fetchUser: jest.fn().mockResolvedValue({ name: 'Alice' }),
}));
test('calls api', () => {
render( );
expect(fetchUser).toHaveBeenCalledWith('1');
});
最易被忽略的一点:Jest 的模块缓存是持久的。改了 mock 实现却不重启 Jest 进程,旧 mock 仍生效;CI 环境里没清缓存也会导致本地通过、CI 失败。遇到“mock 明明写了却不触发”,先试 jest --clearCache。











