17370845950

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 的函数——先把它拆成“数据处理”+“副作用调用”两部分

把业务逻辑抽离为独立函数，测试就自然变得简单、稳定。

覆盖典型输入：正常、边界、错误

一个函数至少测三类情况：

• 正常流程：如 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、贴近真实调用方式，才可持续维护。