javascript单元测试核心是验证单个函数或模块行为，推荐vitest（新项目）或jest（cra项目），专注纯函数、三类输入覆盖、合理mock，避免过度依赖模拟。
JavaScript 单元测试的核心是：用小段代码验证单个函数或模块的行为是否符合预期，不依赖外部环境（如 DOM、网络、数据库）。
选对测试框架和断言库
推荐组合：Jest（开箱即用）或 Vitest（轻量、快、兼容 Vite 项目）。它们都内置断言（expect().toBe()）、模拟（jest.fn()）、覆盖率报告等功能，不用额外配 Babel 或 Webpack。
- 新项目优先用 Vitest：启动快，API 和 Jest 高度一致，支持 ESM 原生导入
- 已有 React + CRA 项目可继续用 Jest：生态成熟，文档丰富
- 避免从零搭 Mocha + Chai + Sinon：配置繁琐，容易卡在环境适配上
只测“纯函数”和明确职责的模块
先写测试再写实现（TDD）不是必须，但要确保被测代码可隔离。比如：
- ✅ 测
calculateTotal(items)：输入数组，输出数字，无副作用 - ✅ 测
formatDate(timestamp)：输入时间戳，输出字符串 - ❌ 暂不测
handleSubmit()直接调用fetch()并更新 DOM 的函数——先把它拆成“数据处理”+“副作用调用”两部分
把业务逻辑抽离为独立函数，测试就自然变得简单、稳定。
立即学习“Java免费学习笔记（深入）”；
覆盖典型输入：正常、边界、错误
一个函数至少测三类情况：
-
正常流程：如
add(2, 3)→5 -
边界值：如空数组、
null、负数、极大数（add(0, 0)、add(-1, 1)） -
异常路径：如传入字符串时是否抛错（
expect(() => add('a', 2)).toThrow()）
不必追求 100% 行覆盖，重点是“行为覆盖”——每种业务意图都有对应用例。
合理使用模拟（Mock），但别过度
模拟是为了控制依赖，不是为了掩盖设计问题：
- 用
jest.mock('./api')拦截模块，返回假数据，避免真实请求 - 用
jest.fn()替换回调，验证是否被调用、参数是否正确 - 避免模拟内置方法（如
Date.now）除非真有时间敏感逻辑；多数时候用参数传入时间更易测 - 如果 mock 层级太深（比如 mock 了三层依赖），说明模块耦合过重，应回头重构
测试代码也是代码——清晰、少 mock、贴近真实调用方式，才可持续维护。
