JavaScript单元测试应聚焦业务逻辑中运算符的边界行为，而非运算符本身；需覆盖类型混合、null/undefined、数值极限、位运算溢出等场景，并用Jest等工具验证实际契约。
在 JavaScript 中，用单元测试验证运算符的边界行为，关键不是“测运算符本身”，而是测你代码中使用这些运算符的逻辑是否在边界输入下表现正确。JavaScript 运算符（如 +、===、??、||、位运算等）有明确的规范行为，但它们和类型、隐式转换、null/undefined、大数、负零、NaN 等组合时，容易暴露逻辑漏洞。单元测试要覆盖这些组合场景。
重点覆盖的边界类型
不必为每个运算符写独立测试套件，而是围绕业务表达式设计用例。常见需验证的边界包括：
-
类型混合运算：比如
'5' + 0（字符串拼接） vs'5' - 0（数值转换），测试你是否预期字符串相加还是数值计算 -
null / undefined 参与逻辑运算：如
value || defaultValue在value = 0或''时是否符合预期；value ?? defaultValue是否正确区分undefined和0 -
数值极限与特殊值：如
Number.MAX_SAFE_INTEGER + 1（精度丢失）、-0 === 0（为 true，但Object.is(-0, 0)为 false）、NaN === NaN（为 false） -
位运算与符号整数：JavaScript 位运算符将操作数转为 32 位有符号整数，
2**31会溢出变负，1.5 | 0结果是1（截断小数）
用 Jest 写可读的边界测试示例
以一个简单但易错的函数为例：
function clamp(value, min, max) {
return Math.min(Math.max(value, min), max);
}它看似安全，但边界上仍有陷阱：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 当
min > max时，结果可能违反直觉（如clamp(5, 10, 3)返回3） - 传入
Infinity或NaN时，Math.max(NaN, 0)返回NaN，可能污染后续逻辑 -
clamp(-0, -1, 1)应保持-0（某些场景需要保留符号）
对应 Jest 测试可写成：
test('clamp handles boundary inputs', () => {
expect(clamp(5, 10, 3)).toBe(3); // min > max
expect(clamp(NaN, 0, 10)).toBeNaN();
expect(Object.is(clamp(-0, -1, 1), -0)).toBe(true);
expect(clamp(9007199254740992, 0, 9007199254740991)).toBe(9007199254740991); // MAX_SAFE_INTEGER+1
});避免“测语言特性”，聚焦业务契约
不要写类似 expect(1 + 1).toBe(2) 的测试——这不是你的责任。要问：这个运算在当前上下文中是否被正确使用？它的结果是否满足业务约束？
- 如果函数接受用户输入字符串并做
+运算，就测'1' + '2'（期望拼接）vs+'1' + +'2'（期望求和） - 如果用
a && b()做条件调用，就测a = 0、a = ''、a = []（所有 falsy 值）是否真的不该触发b() - 对
??，专门对比||：测0 ?? 1（得0） vs0 || 1（得1），确认你选对了空值合并策略
辅助工具提升覆盖率
手动枚举边界易遗漏，可用以下方式补强：
- 用 fast-check 做属性测试：例如声明“对任意数字
a, b，a + b === b + a”，让它自动生成大量边界值（含Infinity、NaN、极大/极小数）验证交换律是否成立 - 在 CI 中启用
eslint-plugin-jest检查测试是否覆盖undefined、null、0、false、''等常见 falsy 输入 - 对数学相关逻辑，用 js-numbers 或
BigInt显式区分安全整数范围，再针对性测试溢出路径
