单元测试在JS中就是“给函数喂数据、看它吐什么、再跟预期对答案”，核心三步：准备（mock依赖、jsdom模拟环境）、执行（传各类参数）、对答案（严格断言）；它通过隔离依赖实现独立运行，是防误改的护栏而非单纯找bug工具。
单元测试在 JS 里，说白了就是“给一个函数喂数据、看它吐什么，再跟我们心里想的对一对”。不靠人点页面、不等接口返回、也不查数据库——就让它孤零零地跑起来，只管自己那一小段逻辑。
核心就三步：准备 → 执行 → 对答案
• 准备：把被测函数需要的东西都安排好。比如它依赖另一个函数，我们就用 mock 暂时替掉；它要读 document，我们就用 jsdom 在 Node 里“假装”有个浏览器环境。
• 执行：调用这个函数，传入特定参数（可能是正常值、空值、非法值、边界值）。
• 对答案：用 expect(result).toBe(5) 这类断言，检查返回值、抛出的错误、甚至是否调用了某个方法——不是“看着像”，而是“必须等于”“必须包含”“必须抛错”。
为什么能“单独跑”？靠的是“隔离”
真实代码往往牵一发而动全身：一个函数可能读 localStorage、发请求、改 DOM。单元测试不希望这些干扰项掺和进来。
所以我们会：
• 用 jest.mock() 把外部依赖“冻住”，让它固定返回想要的数据；
• 用 testEnvironment: 'jsdom' 让测试在模拟的浏览器环境里运行，document.createElement 才不会报错；
• 避免在测试里写 fetch 或 setTimeout ——真要测异步，就用 async/await + waitFor 等它完成，而不是让它真去联网。
它不是“找 bug 的工具”，而是“防手抖的护栏”
你改完一行代码，运行 npm test，几秒内就知道有没有悄悄破坏原有功能。
• 红了 → 哪个 test 块失败、哪行 expect 没过、实际值和预期值差在哪，清清楚楚；
• 绿了 → 这个函数目前的行为是稳定的，你可以放心去优化、拆分、重命名，不用怕“改这儿崩那儿”。
长期下来，测试用例本身就成了最准的说明书：看几个 test 就知道这个函数该处理哪些输入、返回什么、边界怎么兜底。
