要提升核心业务逻辑单元测试的有效性，需聚焦行为承诺、边界值、异常输入、状态变更及依赖隔离，并用分层测试结构和覆盖率诊断补漏。
要让核心业务逻辑的单元测试覆盖率高且真正有用，关键不是堆砌用例数量，而是围绕行为、边界和依赖做精准覆盖。覆盖率数字本身没有意义，80% 的行覆盖如果漏掉关键分支或异常路径，依然可能线上出问题。
聚焦核心行为，按“输入-处理-输出”拆解用例
每个核心函数或方法，先明确它对外承诺的行为——比如“传入合法订单对象，返回含折扣后的总价；传入空对象，抛出错误”。然后为每种典型输入场景写一个测试，而不是盲目覆盖所有参数组合。
- 正常流程：验证主路径逻辑是否正确（如计算、转换、状态更新）
- 边界值：0、null、undefined、空字符串、极大/极小数值、临界长度数组等
- 异常输入：非法类型、格式错误、违反业务规则的数据（如 discountRate > 1）
- 状态变更：如果函数修改了外部变量或实例属性，要断言变更前后状态差异
显式隔离依赖，避免测试失效
核心逻辑常调用 API、数据库、定时器或第三方 SDK。这些外部依赖会让测试变慢、不稳定、难以复现。必须用 mock 替换它们，只测逻辑本身。
- 用 Jest.mock() 或 Vitest.mock() 拦截模块导入，返回可控的模拟响应
- 对异步操作（如 fetch、setTimeout），用 jest.useFakeTimers() 或 vi.useFakeTimers() 控制时间流
- 避免在测试中调用真实网络请求——哪怕加了
await waitFor，也属于集成测试范畴，不该出现在单元测试里
用 describe + test 分层组织，让测试即文档
结构清晰的测试文件本身就是可执行的业务说明书。用嵌套的 describe 表达业务语义，用 test 描述具体行为。
- 顶层
describe('订单结算服务')—— 对应业务模块 - 二级
describe('applyDiscount')—— 对应核心函数 - 每个
test('当折扣率超过100%时应抛出错误')—— 精准描述一个业务规则
这样新成员打开测试文件，不用看源码就能理解这个函数“应该做什么、不该做什么、失败时怎么表现”。
把覆盖率当诊断工具，不是达标指标
配置 coverageThreshold 是为了提醒你遗漏了什么，不是为了凑数字。重点关注三类未覆盖内容：
- 未执行的 if/else 分支：比如只测了成功路径，没测条件不满足时的 fallback
- 未触发的 catch 块：mock 一个被拒绝的 Promise，确保错误处理逻辑跑通
- 未调用的回调或事件监听：尤其在状态机、观察者模式中容易遗漏
运行 npm test -- --coverage --collectCoverageFrom=src/business/** 查看具体哪一行没走，再补对应测试，比盲目加用例更高效。
