提升JS原始类型测试覆盖率的关键是精准覆盖隐式转换、边界极值和特殊组合逻辑三类高风险路径，而非简单增加测试用例；需结合分支覆盖率工具与断言驱动设计，辅以封装可测单元。
JS 原始类型（string、number、boolean、null、undefined、symbol、bigint）操作的测试覆盖率提升，关键不在“写更多测试”，而在于精准识别原始值参与的逻辑分支和隐式转换路径。这类代码看似简单，但大量 bug 隐藏在类型判断、相等性比较、强制转换、边界值处理中——这些恰恰是覆盖率报告里最容易被忽略的“绿区盲点”。
聚焦原始类型特有的高风险路径
原始类型操作的未覆盖代码，往往不是没写测试，而是没测对地方。重点覆盖以下三类场景：
-
隐式类型转换分支：如
==比较、+运算、!value、Boolean(value)、Number(value)等调用中，不同原始值触发的不同转换路径（例如'' == 0为 true，但new String('') == 0为 false） -
边界与极值行为：
Number.MAX_SAFE_INTEGER + 1、parseInt('08')（非严格模式下为 0）、parseFloat('1e309')（返回 Infinity）、String(1e21)（科学计数法输出）、BigInt('0x1fffffffffffff')（安全整数上限） -
特殊原始值组合逻辑：
null == undefined为 true 但null === undefined为 false；typeof NaN === 'number'；Symbol() !== Symbol()；Object.is(-0, +0)返回 false
用断言驱动覆盖，而非用值穷举
不要为每个原始值都写一个 test('string: "a"', ...)。应按语义分组设计断言，确保每条语句/分支都被激活：
- 对类型判断函数（如
isString、isNumberLike），覆盖''、'0'、' '、'123abc'、0、-0、NaN、Infinity、null、undefined、Symbol('s') - 对相等性工具（如
deepEqual或自定义looseEqual），必须包含null/undefined互比、0/-0对比、NaN === NaN（应为 false）与Object.is(NaN, NaN)（应为 true）对比 - 对字符串处理（如
trimStart替代实现、padStart兜底逻辑），覆盖空字符串、全空白字符串（'\t\n\r '）、BOM 字符（\uFEFF）、代理对（'??'）等
借助工具定位“假覆盖”区域
很多原始类型相关代码在覆盖率报告中显示为绿色，实则未真正验证逻辑。使用以下方法揪出问题：
- 启用 分支覆盖率（branch coverage），尤其检查
if (typeof x === 'string')后面的else分支是否执行过；switch (typeof val)是否每个 case（包括 default）都被触发 - 在测试运行时加
--coverage-provider=v8（Jest）或配置nyc的all: true，确保未导入模块、未执行的条件表达式分支也被统计 - 对关键函数使用
console.log或debugger临时打点，确认Number('')确实走到了return NaN分支，而不是被上层 try/catch 吞掉后误判为“已覆盖”
重构辅助：把原始操作封装成可测单元
当原始类型逻辑散落在业务函数中难以覆盖时，主动拆解：
- 将
value && typeof value === 'string' && value.trim().length提取为isValidNonEmptyString(value)，单独为其写 7 个原始值测试用例 - 将
+(val) || 0封装为toSafeNumber(val)，覆盖''、'abc'、null、undefined、Infinity等返回 0 的情况，以及'42'、42等正常转换 - 避免在 if 条件中直接写复杂表达式，改用具名函数——既提升可读性，也天然提升可测试粒度和覆盖率可追踪性
