507-test

name	507-test
description	测试任务：测试本身是主要任务时，用现有框架补行为测试、运行测试、修正过时测试或缩小失败范围；真实生产 bug 转根因修复。Use when user says test, testing, 写测试, 加测试, 补测试, 跑测试, 运行测试, 测试挂了, 测试失败, 修失败测试, 缩小失败范围, coverage.

测试与失败定位（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 故障先修反馈环，不通过改断言掩盖真实失败。