应明确模块边界并用es module显式导出，依赖须显式声明以便mock；对外部依赖需在import后jest.mock；同模块函数调用需通过对象属性导出或手动重写模块；测试应聚焦逻辑、隔离副作用。
明确模块边界与导出方式
要对核心工具模块做独立单元测试，必须先确保它以可测试的方式组织。推荐使用 ES Module 语法，将函数、类或常量显式 export，避免直接挂载到全局或通过闭包隐式暴露。例如：
- ✅ 好的写法：工具函数单独导出，便于按需导入和 mock
export const formatDate = (date) => new Date(date).toLocaleString();
export const debounce = (fn, delay) => { /* ... */ };
- ❌ 避免写法：模块内部直接调用未导出的私有函数，导致无法在测试中替换或验证
如果工具模块依赖其他模块（如 axios、fs 或自定义的 logger），这些依赖必须通过 import 显式声明，不能硬编码或动态 require，否则 Jest 的 jest.mock() 将无法生效。
针对外部依赖做模块级 Mock
当工具模块调用第三方库（如网络请求、文件读写）时，用 jest.mock('xxx') 替换整个模块，控制其行为。关键点是：mock 必须在 import 语句之后、测试用例之前执行。
- 在测试文件顶部 mock 模块，并预设返回值或模拟实现
jest.mock('axios');
const axios = require('axios');
test('fetch config success', async () => {
axios.get.mockResolvedValue({ data: { timeout: 5000 } });
const config = await fetchConfig();
expect(config.timeout).toBe(5000);
});
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 若模块使用默认导出，mock 后需用 jest.requireActual() 保留部分真实逻辑（按需）
处理模块内函数相互调用的 Mock 失效问题
常见陷阱：一个工具模块里，A 函数调用了同模块的 B 函数，你在测试中 mock B 却发现没生效。根本原因是：A 内部引用的是模块作用域内的原始 B，而不是你赋值给 module.exports.B 的 mock 实例。
- 解决方案一：把被依赖的函数作为对象属性导出，让 A 显式通过该对象调用
// utils.js
const helpers = {
sendToEH: (data) => {/* real impl */}
};
exports.sendDataHandler = (req) => helpers.sendToEH(req.body);
exports.helpers = helpers; // 显式暴露供测试替换
- 解决方案二：使用 jest.mock('./utils', () => {...}) 手动重写整个模块导出，强制注入 mock 版本的 helpers
编写聚焦逻辑、隔离副作用的测试用例
单元测试应验证“输入 → 输出”和“交互行为”，不执行真实 I/O。每个测试只覆盖一个关注点：
- 验证函数是否按预期调用依赖（toHaveBeenCalledTimes、toHaveBeenCalledWith）
- 验证不同输入下的返回值（正常路径、空值、错误格式）
- 验证异常是否被正确抛出或捕获（expect(...).toThrow()）
例如测试一个带重试机制的请求工具：
test('retries on network error', async () => {
axios.get.mockRejectedValueOnce(new Error('Network Error'))
.mockResolvedValue({ data: 'success' });
await fetchWithRetry('/api/test');
expect(axios.get).toHaveBeenCalledTimes(2);
});
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
