单元测试核心是验证javascript代码在各种现实输入下是否遵守业务契约，而非仅检测报错；需覆盖null/undefined/0/false、特殊数值、类型混合等边界场景，围绕业务规则断言，揪出静默失败，并用“失败先行”补全缺失分支。
单元测试捕获 JavaScript 逻辑漏洞，核心不是“测代码有没有报错”，而是验证它在各种现实输入下是否始终遵守业务契约。很多漏洞不抛异常、不中断执行，但会悄悄产出错误结果——比如把 0 当成空值处理、把 '' 和 undefined 混为一谈、在数值边界处丢失精度、或因隐式转换导致分支跳过。
覆盖真实边界输入，不只测“正常情况”
逻辑漏洞往往藏在边缘组合里。别只传 1 和 "hello"，要主动构造易被忽略的输入：
-
null / undefined / 空字符串 / 0 / false：检查
||和??是否按业务意图区分它们。例如用户余额为0，应允许查询，但不能被当成“未设置”而触发默认充值逻辑 -
特殊数值：用
Number.MAX_SAFE_INTEGER + 1测试整数精度丢失；用-0和Object.is(-0, 0)验证是否需保留符号；用NaN输入看函数是否提前返回或污染后续计算 -
类型混合：传
'5'和0进同一运算，确认是拼接还是相加；传true给期望数字的参数，观察是否被意外转为1
围绕业务规则写断言，而非语言行为
不要写“expect(5 + 3).toBe(8)”——这测的是 JS 引擎，不是你的逻辑。每个测试用例应映射一条明确的业务规则：
- 如果订单金额 ≤ 0，应拒绝创建并抛出特定错误（而不是静默返回
null） - 当用户角色为
"guest"且未登录时，API 应返回401，且响应体含{ error: "auth_required" } - 时间范围筛选中，若
start > end，应自动交换或抛出 ValidationError，不能返回空数组误导前端
暴露“没报错却做错事”的静默失败
这类漏洞最难发现，因为控制台干净、测试全绿，但数据已错。可通过以下方式主动揪出：
- 对返回对象使用
Object.keys(result).sort()断言字段名完全匹配，防漏字段或拼写错误 - 在异步操作后加
await expect(promise).resolves.toBeDefined()，再单独验证内容，避免因 Promise 拒绝未被捕获而跳过断言 - 对有副作用的函数（如修改入参对象），用
jest.fn()模拟依赖，并断言它是否被调用、以什么参数调用——而不是只看主函数返回值
用测试驱动补全缺失分支
一个常见漏洞是 if/else 或 switch 缺少兜底分支。方法很简单：先写一个“本不该发生但发生了”的输入测试，让它失败；再补上分支让测试通过。
- 比如状态机函数接收
status，目前只处理"pending"和"success"，那就加一个测试：expect(handleStatus("unknown")).toBe("idle") - 若当前返回
undefined导致测试失败，就说明逻辑不完整，必须显式定义未知状态的行为 - 这种“失败先行”的写法，能自然推动你覆盖所有控制流路径
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
