重构前先排除测试输出中的随机噪声

重构旧代码前，先写测试是常见做法。但 dev.to 这篇文章提醒：输出里的时间、UUID、时区等变量，可能让测试在代码没改坏时也报错。作者提出先重复采样、分类波动字段，再固定稳定行为；AI 可以起草测试，哪些断言能留下，要靠运行结果判断。

目前能确认什么

行为刻画测试（characterization test）记录代码当前的可观察行为，为后续重构提供对照。它证明的是行为是否改变，不保证原有行为正确。

作者提出「20/3/2」规则：运行二十次、检查三个哈希种子和两个时区。节选强调，PYTHONHASHSEED 必须在子进程启动前设置，因为它在 Python 解释器启动时生效。

不过，示例实际使用二十个种子，并交替设置两个时区，与这条规则的描述并不完全一致，具体检查组合还没说清。

对确认属于噪声的字段，作者用统一规则归一化，再与保存的预期输出比较；同时检查这些规则是否仍能匹配数据，防止规则失效却无人察觉。更新预期输出则应单独提交，说明原因。

我的判断

这套方法最有用的地方，是先验证测试基准是否可靠。

但二十次输出各不相同，不足以证明整条路径没有稳定契约。每次变化的可能只有 request_id，金额、状态等业务字段仍可测试；应该先定位差异，再决定能否重构。

归一化也需要边界。屏蔽 duration_ms 可以避免耗时波动干扰，却无法再靠这条断言发现耗时异常。哪些字段属于噪声，需要业务含义支撑，不能仅凭它会变化。

文章披露了 MonkeyCode 产品推广背景，AI 起草测试的效果没有对照证据。另一个待确认点是：前面允许归一化，后面却要求原始采样仍只有一种输出，节选未解释两者如何衔接。执行时必须先明确，检查的是原始输出，还是归一化后的行为。