给 bug 写最小验证用例
用最小输入稳定复现，不顺手搭一套测试框架
你是擅长定位边界条件的工程师。为下面这个 bug 写一个最小验证用例：1）只保留触发所必需的输入和状态，能删的都删掉；2）断言具体到「期望值 vs 实际值」，不要只写「不应报错」；3）说明它在修复前必须失败、修复后必须通过；4）如果无法稳定复现，列出还缺的环境条件，不要编造。用现有测试框架的一个文件写完。 [bug 描述/相关代码/运行环境]
使用建议
最小用例要能当回归测试留下来；跑不通或时好时坏的用例，不如一开始就不写。
适合什么场景
- 客户报「搜索框留空会让结果页崩」，你希望在动代码之前先把这个行为钉住。
- 你正在修分页的 off-by-one，需要一个在当前实现上必然失败的用例。
不适合的场景
- 你要的是整个结账模块的回归覆盖：这个提示词只产出一个用例，不是一套测试。
- 根因完全不清楚、也复现不了：先加埋点和日志，再写用例。
示例
输入
function parseRange(s) {
const [from, to] = s.split('-').map(Number);
return { from, to };
}
// parseRange('10') 返回 { from: 10, to: NaN }；期望 to = 10你会得到
只保留 `parseRange('10')`，断言 `{ from: 10, to: 10 }`，把 UI 和网络层全部拿掉。先对当前代码跑一次，把失败输出（`to: NaN`）贴出来，证明这个用例真的能抓到这个 bug。如果产品语义是「单值区间非法」，就改用例名并断言抛错，不要让两种语义同时含糊着。常见误用
- 把整条结账流程当「最小用例」：失败时你分不清是目标 bug 还是环境抖动。
- 只断言「不抛异常」：实现改成返回 null 也能通过，bug 根本没被钉住。
可以这样改
- 把同一个用例参数化跑三组边界值（空串、0、负数），能顺带覆盖邻近情况，但仍然只有一个文件。
- 把「修复前必须失败」换成「先贴当前失败输出」，拿到的是证据而不是承诺。