| name | eo-test |
| description | 根据 change.md 编写并执行单元/集成测试，产出 test.md 报告。严禁修改业务代码。触发：写测试 / 跑测试 / test / /eo-test。 |
eo-test — 测试
根据 change 文档编写并执行单元测试与集成测试，产出结构化测试报告。核心目标是验证而非修复。
职能边界
- 绝对禁令：禁止修改任何非测试相关的业务源码。即便发现 bug，也只能在测试报告中记录并建议修复，不得自行修改源码。
- 操作范围：仅允许修改、新增测试文件、测试目录内容。
- 输出目标：高质量的测试代码覆盖及详尽的
test.md 测试报告。
核心原则
- 以 Change 为准：测试用例严格基于 change.md 中的验收标准与测试规范
- 验证驱动：所有职能围绕"证明代码是否符合预期"展开
- 独立报告：测试结果必须固定产出到
eo-doc/dev/<module-name>/changes/<change-id>/test.md
前置条件
- 必须能找到
.eo-project.json。找不到 → 报错退出，提示运行 /eo-project-init。eo-doc/ 路径通过 doc_root 字段解析
- 对应功能的
eo-doc/dev/<module-name>/changes/<change-id>/change.md 必须已存在
- 相关代码已实现
工作流程
阶段一：单元测试
-
阅读 Change 的测试标准
- 阅读
eo-doc/dev/<module-name>/changes/<change-id>/change.md 中的"单元测试标准"
- 提取每个 TODO 的验收标准
-
编写/优化单元测试
- 仅在测试目录或项目既有测试命名约定下编写代码
- 覆盖正常路径、边界条件、异常场景
-
执行单元测试
-
失败分析与记录
- 如果测试失败：
a. 分析是测试代码本身的逻辑错误，还是业务代码的 bug
b. 如果是测试代码写错了，直接在测试文件中修正
c. 如果是业务代码 bug，停止修改行为，将失败原因记录到测试报告中
阶段二：集成 / 场景验证
-
阅读 Change 的集成测试标准
- 阅读 change.md 中的"集成 / 场景验证标准"
-
编写并执行集成 / 场景验证
- 根据场景编写独立的测试用例或自动化验证流程
- 捕获命令输出、退出码、运行结果作为执行证据
阶段三：产出测试报告
按照下方固定模板撰写，写入 eo-doc/dev/<module-name>/changes/<change-id>/test.md。
固定模板
见 references/test-template.md。
关键约束
- 禁止跨权：严禁修改业务逻辑代码
- 测试独立性：每个测试用例应独立运行，不依赖其他测试的执行顺序
- 不修改 spec/change：测试过程中发现 spec 或 change 的问题，记录到报告中
- 证据完整：每个关键测试场景必须有可验证的执行证据
