为函数生成 Jest 单元测试，覆盖正常路径、边界条件与异常情况。
编程 · 由 周野 维护（CPCX 撰稿人 · 编程与数据）
请为下面的函数编写单元测试，覆盖正常路径、边界条件和异常情况，使用 Jest：
贴函数前先说明预期行为和特殊约束，比如「金额计算，结果保留两位小数」——这些约束恰恰是最容易漏测的地方。复杂函数建议两步走：先让 AI「列出测试用例清单」，你确认哪些有用、哪些多余，再让它写代码。
用例跑不过时，把失败信息原样贴回去，让 AI 自己修自己的用例，通常一轮就能收敛。注意区分是测试写错了还是代码真有 bug，别为了绿灯改断言。
AI 写出的单元测试，正常路径几乎不会出错，真正容易漏的是边界：空数组、只有一项、超长输入、并发调用、金额的四舍五入。在提示词里把这些点自己列一遍（「重点覆盖：空值、单元素、超大数字、时区」），生成的用例会明显更值得留下来。
另一个高价值动作是「先别写实现，告诉我这个函数有哪些边界情况值得测」，让它先列清单，你补几个，再让它写用例。
贴入一个格式化金额的函数，要求覆盖空值、负数、千分位、超长小数。输出里通常会包含 `0`、`-0.005`、`1234567.891` 这些用例。拿到后重点看两件事：断言是不是在测行为而不是测实现细节，以及有没有为了通过测试而修改被测函数——后者一定要拦下来。
假设函数是「按阶梯规则计算订单优惠金额」。把函数源码和业务规则一起贴进去，说明「满 100 减 10，满 300 减 40，金额为负数时视为无效输入」，它生成的测试会覆盖：0 元、99 元（不满足门槛）、100 元（刚好卡在门槛）、300 元、超大金额，以及负数输入抛错这几种情况。
拿到测试后先看它有没有覆盖「刚好等于门槛」这种边界值——这是阶梯类逻辑最容易写错的地方。如果它漏了，直接在追问里点出来让它补上；这一步往往能暴露出你函数实现里本来就存在的问题。
写单元测试是「提前发现问题」，Bug 定位是「已经出问题了再修」。有测试兜底之后，后面用代码重构模板改这块逻辑会安心得多——改完跑一遍测试，就知道有没有改坏。
如果你是先有了 Bug 再考虑补测试，正确顺序是：先用 Bug 定位修好，再让它针对这个 Bug 写一条能失败的回归测试，防止以后改回去。
给现有代码补测试时，把要求改成「先列出这个函数所有可能的分支和输入组合，再按清单逐条写测试」，先出清单再写代码，能避免它只挑好写的路径。
给工具库写测试时，加一句「重点覆盖公开 API 的输入边界，内部实现的测试可以省略」，防止它花大力气去测私有函数，把测试量和维护成本都推上去。
适合给已有的纯函数补测试：输入明确、输出可断言的那种，它写得又快又全。
也适合想不起来该测哪些边界的时候，让它先列一遍再筛。