javascript单元测试是前端重构时保障功能不退化的关键防线，需覆盖核心行为与边界场景、确保隔离可重复、全量验证并通过提升测试质量来指导重构。
前端代码重构时，JavaScript 单元测试是守住功能不退化的关键防线。它不保证重构“更好”，但能明确告诉你——重构后，原来的功能是否还跑得通。
测试必须覆盖核心行为和边界场景
重构前，先确认现有测试已覆盖函数/组件的主要输入输出、异常路径和典型边界值（如空值、极值、异步失败）。如果测试缺失，补全再重构；否则重构就像蒙眼开车。
- 比如一个表单校验函数，不仅要测 “邮箱格式正确 → 返回 true”，还要测 “空字符串、null、超长字符串、特殊符号” 等情况
- 异步逻辑需覆盖 成功、reject、超时、网络中断 等 Promise 状态，避免只测 happy path
- UI 组件测试要检查 props 变化是否触发预期渲染，事件回调是否被正确调用
测试本身要具备隔离性与可重复性
重构过程中，外部依赖（API、localStorage、定时器）容易干扰测试结果。必须用模拟（mock）手段切断耦合，让测试只聚焦被重构单元的逻辑。
- 用 jest.mock() 拦截 fetch 或第三方 SDK，返回可控响应
- 用 jest.useFakeTimers() 控制 setTimeout/setInterval，避免测试等待或超时
- 避免在测试中读写真实 DOM 或全局状态，改用 render + fireEvent（React Testing Library）等安全方式
重构后立即运行全部相关测试，而非只跑改动文件
一个函数的修改可能影响多个调用方。光测当前模块不够，要确保整个测试套件（尤其是涉及该函数的集成路径）全部通过。
- 使用 jest --watchAll 或 CI 中的全量执行策略，防止“局部绿、全局崩”
- 对高频修改模块，可配置 testPathPattern 快速筛选关联测试，但上线前必须回归全量
- 发现测试失败，优先判断是重构引入 bug，还是原有测试本身过时（比如断言依赖了已移除的内部实现细节）
把测试当作重构的导航仪，不是终点线
好的单元测试会清晰描述“这个函数应该做什么”，而不是“它现在怎么做”。重构时，如果发现测试难以理解或过度依赖实现细节（比如断言某个私有变量值），说明测试质量也需要同步提升。
- 将 “expect(fn()).toBe(42)” 替换为 “expect(fn(6, 7)).toBe(42)”，让输入输出更明确
- 删除基于内部状态（如 mockFn.mock.calls）的脆弱断言，改用行为验证（如“点击按钮后弹窗出现”）
- 给测试用例起描述性强的名字，例如 “当用户未登录时，提交表单应跳转至登录页”，而非 “test case 3”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
