507 test

测试与失败定位（test）

专门处理测试资产和失败诊断。它观察公开行为、缩小失败范围并补足关键覆盖，不承担真实生产 bug 的实现修复。

原则

1. 测试公共接口和调用者关心的行为，不锁定私有方法、内部字段或调用次数。
2. 沿用项目已有测试框架、命令、命名和目录，不为单个任务引入新测试栈。
3. mock（模拟）只放第三方服务、数据库、时间、随机数、文件系统等系统边界，不 mock 自己的内部协作者。
4. 断言具体输出、状态、错误或副作用，不只断言“没有报错”。
5. 失败先分类，不直接改断言把红灯变绿。
6. 如果测试必须穿透大量内部结构或伪造巨大对象，先怀疑模块形状和公开接口。

工作流程

1. 明确任务

判断是新增测试、运行测试、修失败测试、缩小失败范围，还是覆盖关键边界。确认预期行为、公开入口、已有命令和项目测试约定。

2. 读取证据和惯例

修失败测试时先读完整输出，定位首个真实失败。再读相邻测试、fixture（测试样本）、项目说明和局部规范，理解当前测试接缝。

3. 选择最高公开接缝

优先使用公开 API（接口）、CLI（命令行）、页面或其他真实入口。内部重命名、拆函数或替换实现不应让行为测试失效。

4. 编写最小有效测试

• 测试名描述行为场景；
• 优先主路径、重要边界和关键错误路径；
• 不追求无价值的全组合覆盖；
• partial（局部对象）或故意错类型只允许用于测试构造，不进入生产代码。

5. 递进运行

依次从单个用例、单个文件/包、相关集合扩大到项目要求的完整测试或构建检查。记录命令、结果和首个失败证据。

失败分类与路由

• 生产行为不符合既定规格：保留测试作为反馈环，转 507-fix；
• 规格已改变：先确认新规格，再更新测试和相关说明；
• 测试过时：只调整测试，使其回到公开行为和当前约定；
• fixture、编译、依赖或环境故障：修测试环境，不伪装成产品行为；
• 用户明确要求 test-first（测试先行）或 TDD（测试驱动开发）：转 507-tdd。

交付

报告新增/修改的测试、覆盖行为、运行命令与结果、失败分类、路由和未覆盖边界。测试稳定后可用 507-review 独立审查；用户明确要求提交时再用 507-commit。

完成与接力

• 完成信号：目标行为已有稳定测试或失败已完成可信分类，相关测试层级和构建检查结果已报告。
• 产物：测试资产、运行证据、失败分类与未覆盖边界。
• 候选出口：生产行为错误进入 507-fix；规格变化进入 507-grill / 507-prd；明确 test-first 请求进入 507-tdd；测试工作完成后进入 507-review，用户明确要求提交时再进入 507-commit。
• 回退条件：环境或 fixture 故障先修反馈环，不通过改断言掩盖真实失败。