automate-tests

技能：运行自动化测试

目的

弄清目标仓库要求如何运行自动化测试（命令、框架、前置条件和范围），然后在安全优先的交互策略下运行最匹配的测试套件。

---

核心目标

主要目标：通过基于证据的命令选择和安全防护措施，生成测试执行结果。

成功标准（必须全部满足）：

1. ✅ 已发现测试计划：已确定证据来源（文档、CI 配置或构建清单）
2. ✅ 已选择命令：根据模式（快速/CI/完整）和约束，选择了合适的测试命令
3. ✅ 已获得用户确认：在安装依赖、使用网络或启动服务之前，已获得批准
4. ✅ 已执行测试：已运行命令，并记录其输出和退出代码
5. ✅ 已总结结果：提供包含证据、命令、执行状态和失败项（如有）的测试计划摘要

验收测试：开发者能否仅根据测试计划摘要，在无需额外背景信息的情况下复现测试执行？

---

范围边界

此技能负责：

• 根据仓库证据（文档、CI、构建清单）发现测试命令
• 根据模式和约束选择合适的测试命令
• 在安全防护措施和用户确认下执行测试
• 总结测试结果，并提供证据和失败诊断信息

此技能不负责：

• 评估测试质量或分析覆盖率（使用 review-testing）
• 修复失败的测试或调试测试失败问题（使用 orchestrate-repair-loop）
• 编写新测试或测试基础设施（使用开发技能）
• 根据最佳实践审查测试代码（使用 review-testing）

交接点：测试结束后（无论通过还是失败），将任务交给 orchestrate-repair-loop 修复失败项，或交给 review-testing 进行质量评估。

使用场景

• 你克隆了一个仓库，希望找到正确的测试命令，而不是靠猜测。
• 仓库有多个测试层（单元测试/集成测试/e2e），你需要一个安全的默认运行计划。
• CI 失败了，你想通过运行工作流使用的相同命令，在本地复现问题。

行为

1. 明确范围和限制（不清楚时询问）

   • 如果用户没有指定任何内容，默认执行快速、本地、非破坏性的运行：
     • 仅运行单元测试，不使用外部服务、Docker 或依赖网络的设置。
   • 在有必要时，让用户选择模式：
     • fast：仅运行单元测试，尽量减少设置。
     • ci：尽可能贴近 CI 工作流中的命令。
     • full：包含集成 / e2e 测试和服务依赖项。
   • 询问是否允许使用 Docker、网络访问和安装依赖项。

2. 确定测试计划（以证据为依据）

   • 如果存在 CLAUDE.md 或 .ai-cortex/config.yaml，优先使用其中记录的 test_command；否则从下列来源中查找。请参阅 docs/guides/project-config.md。
   • 按以下顺序读取这些来源；一旦找到明确无歧义的测试命令，就提前停止：
     • README.md、CONTRIBUTING.md、TESTING.md、docs/testing*、Makefile
     • CI 配置：.github/workflows/*.yml、.gitlab-ci.yml、azure-pipelines.yml、Jenkinsfile
     • 构建清单：package.json、pyproject.toml、setup.cfg、tox.ini、go.mod、pom.xml、build.gradle*、*.csproj、Cargo.toml
   • 确定：
     • 主要测试入口（npm test、pnpm test、yarn test、pytest、tox、go test、dotnet test、mvn test、gradle test、cargo test 等）
     • 测试层级和标记（单元测试、集成测试、e2e）
     • 环境前置条件（数据库、Redis、Docker Compose、必需的环境变量、密钥）
     • CI 如何设置依赖项（服务、缓存、构件）
   • 优先采用文档或 CI 中的明确说明，而非启发式推断。

3. 选择执行计划

   • 在 ci 模式下：根据仓库的 CI 工作流步骤推导运行顺序（尽可能匹配）。
   • 在 fast 模式下：选择最直接、前置条件最少的单元测试命令。
   • 如果存在多个技术栈（例如后端 + 前端），建议按固定顺序分别运行各技术栈的测试。
   • 如果计划需要安装依赖项或启动服务，继续之前先征求确认。

4. 设置防护措施后执行

   • 始终先打印即将运行的确切命令，再运行它。
   • 使用以目标仓库为根目录的工作目录（默认为 .）。
   • 捕获并总结失败信息：
     • 首个失败的命令及其退出码
     • 最相关的错误摘录
     • 后续操作（缺少工具链、缺少环境变量、服务未运行等）
   • 避免破坏性操作：
     • 未经用户明确批准，不要运行 rm -rf、git clean -fdx、docker system prune 或数据库删除 / 迁移命令。
   • 如果仓库需要密钥，不要要求用户在聊天中粘贴。请使用 .env 文件、密钥管理器或文档说明的本地开发流程。

输入与输出

输入

• 目标仓库路径（默认为 .）。
• 模式：fast（默认）、ci 或 full。
• 限制：是否允许安装依赖项（是 / 否）、是否允许访问网络（是 / 否）、是否允许使用 Docker（是 / 否）。

输出

• 一份简短的“测试计划摘要”，包含：
  • 依据：为制定计划参考的文件 / 路径
  • 选定的命令（按顺序排列）
  • 假设和前置条件
  • 已执行和跳过的内容（及原因）
• 提供足够的命令日志，以便调试失败（除非用户要求，否则不要输出极长的日志）。

限制

硬性边界

• 如果已有证据，不要凭空编造测试命令（应以文档 / CI 为准）。
• 未经确认，不要安装依赖项、运行 Docker 或启动外部服务。
• 除非用户明确要求，否则不要修改仓库文件（例外：用户要求生成报告文件作为交付物时）。
• 不要泄露密钥；不要在聊天中索要敏感凭据。

技能边界（避免重叠）

不要执行以下操作（由其他技能负责）：

• 测试质量评估：判断测试覆盖率、测试设计或测试最佳实践 → 使用 review-testing
• 修复测试失败：调试失败的测试、修复损坏的测试代码或追查根因 → 使用 orchestrate-repair-loop
• 编写测试：创建新的测试用例、测试基础设施或测试框架 → 使用开发／实现技能
• 代码审查：审查测试代码的质量、可维护性或最佳实践 → 使用 review-testing
• 仓库分析：全面分析代码库结构或审查架构 → 使用 review-codebase

何时停止并移交：

• 测试失败，且用户询问“为什么？”或“如何修复？” → 移交给 orchestrate-repair-loop 进行调试和修复
• 用户询问“这些测试质量如何？”或“我们的覆盖率是多少？” → 移交给 review-testing 进行质量评估
• 用户询问“能为 X 编写测试吗？” → 移交给开发工作流来实现测试
• 测试通过，且用户询问“接下来应该测试什么？” → 将测试策略建议移交给 review-testing

自检

核心成功标准（必须全部满足）

• 已找到测试计划：已确定证据来源（文档、CI 配置或构建清单）
• 已选择命令：已根据模式（fast／ci／full）和限制选择合适的测试命令
• 已获得用户确认：在安装依赖、使用网络或启动服务之前已获得批准
• 已执行测试：已运行命令，并记录其输出和退出代码
• 已总结结果：提供测试计划摘要，包含证据、命令、执行状态及失败情况（如有）

流程质量检查

• 基于证据进行选择：我是否确定了至少一个测试命令的权威来源（文档文件、CI 工作流或构建清单）？
• 已应用安全防护措施：在安装依赖、使用网络、启动 Docker／服务或执行任何会更改状态的操作之前，我是否征求了确认？
• 已打印命令：运行之前，我是否打印了准确的命令？
• 已诊断失败：测试失败时，我是否提供了首个失败命令、退出代码和可能的根因类别？
• 未执行破坏性操作：未经明确批准，我是否避免运行破坏性命令（rm -rf、git clean、docker system prune、删除数据库）？
• 未泄露机密：我是否避免在对话中索要敏感凭据，并改用 .env 文件或文档所述的本地开发流程？

验收测试

开发者能否仅按照测试计划摘要，在没有额外上下文的情况下重现测试执行过程？

如果不能：测试计划摘要不完整。请补充缺失的证据、命令或前置条件。

如果能：技能运行已完成。如有需要，请继续移交。

示例

示例 1：使用 package.json 的 JavaScript 仓库

用户：“运行此仓库的测试。”

Agent：

1. 检查 package.json 中的脚本和 .github/workflows/*。
2. 确定采用 fast 模式，并提出：
   • npm test（如果仓库统一使用 pnpm 或 yarn，则使用 pnpm test 或 yarn test）
3. 询问：“是否安装依赖（npm ci）并允许访问网络？”
4. 运行：
   • npm ci
   • npm test
5. 总结结果；如有失败，请指出失败测试的输出。

示例 2（边缘情况）：需要 Docker 运行集成测试的 monorepo

用户：“在本地复现 CI。”

Agent：

1. 解析 .github/workflows/ci.yml 并识别不同的任务：
   • 后端单元测试
   • 前端测试
   • 使用 docker compose 的集成测试
2. 请求确认：
   • 是否允许使用 Docker
   • 是否允许联网
   • 要运行哪些任务（全部运行，还是只运行失败的任务）
3. 按受控顺序执行：
   • 按任务安装依赖
   • 先运行单元测试
   • 启动集成测试所需的服务
4. 如果集成测试失败，请总结：
   • 服务健康状况／端口冲突
   • 缺少的环境变量
   • CI 配置与本地配置的差异