test

测试执行流程

第一步：分析 pending changes

运行以下命令了解当前改动：

• git status — 哪些文件有变更
• git diff — 具体改了什么

第二步：发现可用的测试命令

自动检测项目中可用的测试方式，按优先级尝试：

1. package.json scripts：检查 scripts 中包含 test、jest、vitest、mocha、cypress 等关键词的命令
2. Makefile：查找 test 目标
3. 常见测试入口：查找根目录下的 test-e2e.mjs、test*.js、test*.mjs、test*.py、test*.sh 等文件
4. pytest / go test / cargo test：根据项目语言自动推断

列出发现的测试命令，让用户确认或选择。

第三步：设计测试策略

根据变更内容，向用户说明测试计划并确认：

1. 这次改动涉及哪些模块？ 根据变更文件的路径、命名推断（如改了路由 → API 相关，改了样式 → UI 相关，改了配置 → 配置相关）
2. 需要跑真实 API 还是 mock 测试就够？
   • mock 测试：零消耗，验证逻辑和接口契约
   • 真实测试：消耗 token，但验证端到端真实行为
3. 哪些测试该跑？哪些可以跳过？为什么？
   • 根据变更模块，匹配对应的测试范围
   • 没改到的模块 → 跳过，节省时间
4. 预估消耗（如有 token/API 调用成本）

格式示例：

本次改动：src/routes/api.js 中新增了 /api/query 端点

建议测试策略：

• 发现测试命令：npm test、node test-e2e.mjs
• 跑 mock 测试即可（不消耗 token，验证接口契约）
• 需要跑：核心流程测试（确认未破坏现有端点）
• 可以跳过：文件操作、PII 相关（未涉及）

等待用户确认后再执行。

第四步：执行测试

用户确认后，运行对应的测试命令。

支持选择性运行：

• 如果测试框架支持 --only、--grep、-k 等过滤参数，按模块名过滤
• 如果是直接执行脚本，按函数名/描述子串匹配

注意：跳过的测试可能有依赖链，如果需要验证完整链路，跑全量测试更可靠。

第五步：结果报告

测试完成后报告：

• 通过 / 失败数量
• 失败的测试名和关键原因
• 全部通过则确认即可