重构前，先验证行为测试能抓住错误

重构前测试全绿，改完依然全绿，是否就能放心合并？dev.to 的这篇文章提出：先故意改坏一处行为，看测试能不能报错。作者用 Python 示例串起输入输出采集、参数化测试和行为探测，试图解决遗留代码重构中「测试通过，业务行为却悄悄变化」的问题。

目前能确认什么

作者建议先运行现有测试或脚本任务，记录函数的真实参数和返回值，再用 pytest 生成参数化测试，固定当前行为。这类测试称为特征测试（characterization test），保存的是代码今天的表现，其中可能包含已有缺陷，并不代表业务规则正确。

随后，在仓库副本里施加小改动，例如给金额结果增加偏差，或把边界判断从 >= 改成 >，检查测试是否失败。测试仍通过，就暴露了样例或断言的盲区；补丁没有应用成功、测试收集出错，则不能算验证成功。

作者还要求先排除采集数据过期、输出不稳定等问题，并在重构中保留原始基线。测试变红后直接重新采集，会把待调查的行为变化一起写进预期结果。

我的判断

全绿只说明当前样例和断言没有发现差异，不能单独证明重构安全。

对程序员最有用的，是把重构中担心改错的地方变成探针：金额处理看精度，条件分支看边界，结果列表看顺序。但探针必须对应测试可观察的行为。函数只返回总额时，单靠这个返回值无法验证行顺序。

这套方法也有明确边界：真实任务没经过的路径，采集不会自动补齐；探针触发失败，也只证明测试能抓住该项变化。

节选中的执行脚本仍需谨慎使用。它排除了退出码 2，却把其余非零退出都归为预期失败，不能充分证明失败来自目标断言。文末关于 AI 辅助生成探针、隔离执行的内容被截断，具体工具能力和执行保障还无法确认。