eo-test

name	eo-test
description	根据 change.md 编写并执行单元/集成测试，产出 test.md 报告。严禁修改业务代码。触发：写测试 / 跑测试 / test / /eo-test。

eo-test — 测试

根据 change 文档编写并执行单元测试与集成测试，产出结构化测试报告。核心目标是验证而非修复。

职能边界

1. 绝对禁令：禁止修改任何非测试相关的业务源码。即便发现 bug，也只能在测试报告中记录并建议修复，不得自行修改源码。
2. 操作范围：仅允许修改、新增测试文件、测试目录内容。
3. 输出目标：高质量的测试代码覆盖及详尽的 test.md 测试报告。

核心原则

1. 以 Change 为准：测试用例严格基于 change.md 中的验收标准与测试规范
2. 验证驱动：所有职能围绕"证明代码是否符合预期"展开
3. 独立报告：测试结果必须固定产出到 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 必须已存在
• 相关代码已实现

工作流程

阶段一：单元测试

1. 阅读 Change 的测试标准

   • 阅读 eo-doc/dev/<module-name>/changes/<change-id>/change.md 中的"单元测试标准"
   • 提取每个 TODO 的验收标准

2. 编写/优化单元测试

   • 仅在测试目录或项目既有测试命名约定下编写代码
   • 覆盖正常路径、边界条件、异常场景

3. 执行单元测试

   • 运行项目测试命令收集结果

4. 失败分析与记录

   • 如果测试失败： a. 分析是测试代码本身的逻辑错误，还是业务代码的 bug b. 如果是测试代码写错了，直接在测试文件中修正 c. 如果是业务代码 bug，停止修改行为，将失败原因记录到测试报告中

阶段二：集成 / 场景验证

1. 阅读 Change 的集成测试标准

   • 阅读 change.md 中的"集成 / 场景验证标准"

2. 编写并执行集成 / 场景验证

   • 根据场景编写独立的测试用例或自动化验证流程
   • 捕获命令输出、退出码、运行结果作为执行证据

阶段三：产出测试报告

按照下方固定模板撰写，写入 eo-doc/dev/<module-name>/changes/<change-id>/test.md。

固定模板

见 references/test-template.md。

关键约束

• 禁止跨权：严禁修改业务逻辑代码
• 测试独立性：每个测试用例应独立运行，不依赖其他测试的执行顺序
• 不修改 spec/change：测试过程中发现 spec 或 change 的问题，记录到报告中
• 证据完整：每个关键测试场景必须有可验证的执行证据