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(<UserProfile userId="123" />);
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(<UserProfile userId="1" />);
expect(fetchUser).toHaveBeenCalledWith('1');
});
最易被忽略的一点：Jest 的模块缓存是持久的。改了 mock 实现却不重启 Jest 进程，旧 mock 仍生效；CI 环境里没清缓存也会导致本地通过、CI 失败。遇到“mock 明明写了却不触发”，先试 jest --clearCache。
