测试全部通过，却偷偷污染了生产日志：一个Python测试隔离教训

软件测试里有一句常被忽略的真相：测试通过只能证明你断言的那部分行为是对的，却对代码在执行过程中顺手做的其他事情一无所知。一位开发者在整理自己的评论回复流水线时，就撞上了这个盲区——离线测试套件全部通过，背后却悄悄往生产日志里写入了122条合成数据。

事情是怎么发生的

这位开发者维护着一个评论投递流水线，每次检查自己发出的回复是否真的出现在页面上，就会往一个生产日志 landing-observations.jsonl 追加一行 JSON，记录文章、评论、是否成功投递以及第几次尝试成功。这个日志的定位很明确：它是关于真实投递的证据，后续还有其他决策（比如回复重试预算的评审）会读取它。

问题出在 watcher、autoreply 和 reply 三个用 Python unittest 写的测试套件上。其中一部分测试会触发投递检查逻辑：喂给观察器临时的 HTTP 数据，然后断言它的判断结果。喂进去的假数据是临时的，但输出路径没有被隔离——测试运行时，观察器照样把结果写进了真实的 landing-observations.jsonl。

测试污染生产日志问题示意

第一次完整基线运行追加了 30 行合成数据，而那次运行报告的是 176 个测试全部 OK。后续在修复 fixture 隔离之前的几次完整运行又追加了更多。最终合成行累计达到 122 条（中间一份简报曾估算为 145，按时间戳和目标逐行核对后确认为 122）。

为什么“通过”什么也没告诉你

测试通过，意味着它的断言成立。这些断言关心的只是投递检查返回了什么：成功还是失败、尝试次数是否被计入。没有一个断言去问代码在这个过程中还碰了什么别的东西。

往测试沙箱之外的文件写一行，不会让任何断言失败，pass/fail 机制甚至根本不会察觉到这个动作。作者把这句话说得很透彻：这些套件对它们测试的行为判断是正确的，但对它们没测试的副作用保持了沉默——而这个副作用恰好落进了一个“唯一职责就是保证内容真实”的文件里。

这正是绿色测试给人虚假安全感的核心机制。断言覆盖的是行为的输出，而副作用（文件写入、网络调用、全局状态修改）往往游离在断言的视线之外。

清理：用精确归因而非粗暴删除

面对被污染的日志，有几种又快又“脏”的清理方式：直接截断文件、删掉测试运行时间窗内的所有行、或者用旧备份覆盖线上文件。但每一种都有风险——可能连带删掉同一时间窗内写入的真实观察，或是备份时间点之后产生的真实数据。

作者采用的是精确归因。那些合成行带着可识别的 fixture 特征值，可以通过精确的时间戳、目标以及每种组合出现的次数来匹配。处理流程分两步：先把这些行连同原始 JSON 完整保存到一个恢复备份里，再精确地从日志中移除它们。最终 623 条真实生产数据原封不动，文件停在 97,094 字节。

这里有一个值得记住的原则：如果这些行无法被精确归因，正确的做法是把它们留在原地，并把污染记录为日志的一个已知局限，而不是靠猜测去删。 对一个作为证据存在的文件来说，宁可带着已知的瑕疵，也不要引入不确定的损坏。

修复方案：先隔离，再加护栏

首要修复是隔离。watcher 和 autoreply 的测试现在把观察文件重定向到一个临时 fixture 路径，让被测代码写到一个用完即弃的地方；reply 套件的投递测试则改为 mock 掉 watcher 而不是真正调用它。

Python 的 tempfile 模块是制造这种“一次性位置”的标准工具。作者给出的模式大致如下（示意性命名）：

class LandingCheckTests(unittest.TestCase):
    def setUp(self):
        tmp = tempfile.TemporaryDirectory()
        self.addCleanup(tmp.cleanup)
        patcher = mock.patch.object(watcher, "OBS_PATH",
                                    Path(tmp.name) / "observations.jsonl")
        patcher.start()
        self.addCleanup(patcher.stop)

如果用的是 pytest，tmp_path fixture 可以达到同样的目的；这些套件是 unittest，所以没用它。

第二部分是一道护栏，它能让这个问题在第一次就被抓住。watcher 套件现在有一个 teardown 断言，比较真实日志在测试前后的字节数；外层包装器在整个套件运行和共享检查前后做同样的比较。字节比较很粗糙——而这恰恰是重点：它不需要知道哪条代码路径可能写文件，只需要知道这个文件绝不能变。

作者特别点明了两者的分工：事后的护栏并不能撤销一次写入，它只是把一个沉默的副作用变成一次失败的运行；而隔离才是从根本上阻止写入发生的东西。 护栏是补网，隔离是堵源。

Python unittest 中的 mock.patch.object 是标准库 unittest.mock 提供的上下文管理器/装饰器，它能在测试期间临时替换某个对象的属性或方法，测试结束后自动还原。在这里，它把 watcher 模块的 OBS_PATH 变量替换成一个指向临时目录的路径，被测代码在不知情的情况下把输出写到那个临时位置而非真实日志。addCleanup 是 unittest.TestCase 的一个机制，它注册一个在测试结束时无论成功还是失败都会执行的回调——比 tearDown 更可靠，因为即便 setUp 中途抛异常，已注册的 cleanup 仍然会运行。tempfile.TemporaryDirectory() 则会在系统临时空间创建一个唯一目录，并在 cleanup() 被调用时连同目录内的所有文件一起删除，从根本上保证了测试产生的临时文件不会遗留。

验证结果与新的检查习惯

修复之后，223 个 watcher、autoreply、reply 测试全部通过，生产日志逐字节未变，依然是 97,094 字节。

一个共享的离线测试框架覆盖五个组件，通过了 203 个测试（140 watcher、42 telemetry、7 browser、14 grammar）。作者特意说明 223 和 203 有重叠（都含 watcher 测试），所以不能相加。Claude Code、Codex 和 agy 各自从项目外的临时目录运行了这个共享检查器——它不调用任何模型、不发布任何内容，全程离线且合成，因此也无法说明真实浏览器会话在生产中的表现。

这件事改变了作者对测试的提问方式。字节护栏只覆盖了他现在已知的那一个文件，它找不到测试可能写入的其他路径。所以对任何触碰真实 I/O 的套件，他现在要问的不只是“它通过了吗”，而是“它写了什么、写到哪里”。对一个会被其他决策读取的日志而言，答案必须是“什么都没写”，而且必须有东西去验证这一点。

给工程师的启示

这个案例虽小，却精准地击中了测试工程中一个普遍盲区。几点可以直接借鉴：

测试通过 ≠ 代码干净。断言只覆盖你明确检查的输出，副作用往往在视线之外。
真实 I/O 必须隔离。文件路径、数据库连接、外部服务地址都应该在测试里被重定向到一次性位置，tempfile 和 mock 是基础工具。
用护栏把沉默变成尖叫。字节级或状态级的前后对比虽然粗糙，但能把本来悄无声息的污染变成一次明确的失败。
清理数据时优先精确归因。能精确识别就精确移除，不能识别就如实记录为局限，不要靠猜测破坏证据的可信度。

当你的测试会触碰那些“唯一职责就是保持真实”的数据时，隔离和护栏就不是可选项，而是底线。

背景补充

这种现象在测试理论中通常被归纳为"副作用不可见性"问题。测试框架的 pass/fail 判定完全由断言（assert）语句驱动：没有断言失败就算通过，框架本身不会主动监控被测代码对外部状态的改动。文件写入、数据库插入、环境变量修改、全局单例状态变更都属于"副作用"，它们可以在零断言失败的情况下悄然发生。这也是为什么测试覆盖率（coverage）指标具有误导性——100% 的行覆盖率只意味着每行代码都被执行过，并不意味着执行产生的所有后果都被验证过。真正意义上的测试健壮性需要同时关注输入-输出的断言覆盖和副作用的隔离程度，两者缺一不可。