JS单元测试思维导图主线是“测什么→怎么测→怎么写→怎么保障质量”，聚焦测试目标、断言逻辑、异步处理、Mock策略、测试组织五大高频痛点，强调按功能域而非文件路径组织用例。
画 JS 单元测试的思维导图，关键不是堆砌工具名，而是理清“测什么→怎么测→怎么写→怎么保障质量”这条主线。重点落在测试目标、断言逻辑、异步处理、Mock 策略和测试组织这五个真实开发中高频踩坑的环节。
明确测试对象：函数、模块、行为，而非代码行
导图第一层应区分被测单元类型：
- 纯函数：输入确定 → 输出确定，重点覆盖边界值、异常输入（如空参、NaN、null）
- 有副作用的函数：调用 API、修改 DOM、触发事件——需识别依赖并隔离
- 模块级行为：如一个工具类的多个方法协同工作，测试关注接口契约而非内部实现
断言设计：从“是否相等”升级到“是否符合预期行为”
避免只写 expect(result).toBe(42) 这类静态断言。导图中要单列“行为断言”分支：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 验证函数是否被调用：
expect(mockFn).toHaveBeenCalled() - 验证调用参数：
expect(mockFn).toHaveBeenCalledWith('a', true) - 验证返回值结构：
expect(res).toHaveProperty('id')或expect(res).toMatchObject({ status: 'ok' }) - 验证抛出错误：
expect(() => fn()).toThrow(/invalid/)
异步测试必须显式声明控制权
JS 异步是测试失焦重灾区。导图中“异步”节点下要强调三种写法对应场景：
- async/await：适用于 Promise 返回函数，直接 await 调用，配合 expect 断言
- done 回调：仅在旧版 Jest 或需手动控制结束时使用，忘记调用 done 会导致超时失败
- return Promise：函数体返回 Promise，Jest 自动等待其 resolve/reject
Mock 不是为了“绕过”，而是为了“约束依赖”
导图中 Mock 分支应按目的划分，而非 API 列表：
-
模拟外部服务：用
jest.mock('./api')替换真实请求，返回预设响应 -
拦截全局行为：如 mock
setTimeout防止测试等待，或 mockconsole.error捕获警告 - 隔离模块耦合：对被测模块 import 的其他模块做自动 mock，避免副作用扩散
-
注意清理：每个 test 用
jest.clearAllMocks()或afterEach重置状态
测试文件结构要反映业务逻辑，而非源码路径
不要机械地按 src/utils/xxx.js → tests/utils/xxx.test.js 映射。导图中建议按“功能域”组织：
- 比如用户登录流程，把表单校验、API 调用、错误提示、跳转逻辑的测试放在同一组
login.spec.js中 - 用
describe划分场景（如 “提交空邮箱时”、“服务器返回 500 时”） - 每个
it只验证一个明确行为，名称用 “should … when …” 句式，如should show error message when email is empty
