第二十四章：实验四，用测试把设计承诺固定下来

24.1 二十四项测试覆盖什么

随书测试覆盖完整修复、完成恢复、当前状态再验收、模型空口成功、只读拒绝、路径越界、符号链接、保留日志路径、schema、过期哈希、截断流、缺失结束、参数分片、重复 ID、请求预算、工具预算、未知结果、大附件、取消、写锁、破损尾部、篡改检测、模型临时重试和任务配置变化。

它们没有声称覆盖生产系统的全部故障。没有真实模型网络、Shell 子进程、跨机器存储和恶意竞争者。测试报告中的通过，应和这些覆盖条件一起解释。

“写权限关闭时结果为 denied”只检查了一半。还要检查文件没有被修改，最终没有 run.finished。类似地，unknown 恢复测试既检查状态，又检查模型没有被调用，原外部状态没有被第二次操作覆盖。

这种断言把行为与副作用连接起来。相比检查某个私有函数调用次数，它对重构更有价值。实现可以改变，但被拒绝不产生写入、最终回答不代替验收等约束应当保留。

给每项测试写一个阶段标签：输入接纳、流接收、调用校验、执行前、执行后、结果保存、恢复或验收。这样可以发现空白。例如，本书测试构造了结果缺失，却没有断电测试文件系统持久性；这属于明确的剩余工作，而不是被二十四个绿色结果覆盖了。

真实生产系统还应增加进程被强制终止、磁盘满、网络中断、服务端重复响应、版本迁移和并发写入等测试。它们可能需要容器或专门环境，不应伪装成在普通单元测试里已经验证。

暂时把 Engine 的最终 acceptance 判断改成恒真，再运行测试。test_final_text_is_not_completion_evidence 应失败。把路径保留目录检查删除，相关测试也应失败。这样的试验能帮助你确认测试真的针对设计约束，而不只是恰好跟着当前代码运行。

请在自己的练习分支做这些改动，完成后恢复。书中的实测结果对应未作反向修改的完整代码，不能把故意破坏后的测试状态当作发布版本。

Pi 提供模型流注入与截断处理的阅读依据；DeepSeek 提供日志视图、调度与生命周期的实例；Claude Code 提供工具执行器与结果预算的实例；Codex 提供输入、工具计划与执行编排的实例。

实验借鉴的是这些工程问题与边界，而不是复制上游协议。你可以带着测试问题返回原工程：它的保证在哪一层、有哪些配置条件、如果想验证还需要什么环境？这比宣布“我用几百行实现了四套产品”更加准确，也更有学习价值。