fix-tests

修复测试

用户参数

用户可以指定要关注的测试或模块：

$ARGUMENTS

如果未提供任何内容，则关注所有测试。

上下文

业务逻辑变更、重构或依赖项更新后，测试可能会失败，因为它们不再符合当前行为或实现。此命令会协调专用 Agent，自动修复所有失败的测试。

目标

修复所有失败的测试，使其符合当前业务逻辑和实现。

重要约束

• 专注于修复测试——除非绝对必要，否则不要更改业务逻辑
• 保留测试意图——确保测试仍能验证预期行为
• “分析变更的复杂度”——
  • 如果有 2 个或更多文件发生变更，或某个文件包含复杂逻辑，则不要自行编写测试——只协调 Agent！
  • 如果只有 1 个文件发生简单变更，则可以自行编写测试。

工作流步骤

准备

1. 如果有 sadd 技能，则阅读

   • 如果有 sadd 技能，请阅读它，了解管理 Agent 的最佳实践

2. 了解测试基础设施

   • 阅读 @README.md 和 package.json（或等效的项目配置）
   • 确定运行测试和生成覆盖率报告的命令
   • 了解项目结构和测试惯例

3. 运行所有测试

   • 执行完整测试套件，以建立基线

4. 找出所有失败的测试文件

   • 解析测试输出，获取失败测试文件列表
   • 按文件分组，以便并行执行 Agent

分析

5. 验证单个测试的执行
   • 选择任意一个测试文件
   • 启动 haiku Agent，指示其找出仅运行此测试文件的正确命令
     • 要求其反复尝试，直到能够可靠地运行单个测试
   • 完成后，尝试运行某个特定测试文件（如果存在）
   • 这可确保 Agent 能够单独运行测试

修复测试

6. 并行启动 developer Agent

   • 为每个失败的测试文件启动一个 Agent
   • 为每个 Agent 提供清晰的指示：
     • 上下文：此测试需要修复的原因（业务逻辑已变更）
     • 目标：需要修复的具体文件
     • 指导：阅读 TDD 技能（如果有），了解编写测试的最佳实践。
     • 资源：阅读 README 和相关文档
     • 命令：运行此特定测试文件的方式
     • 目标：反复迭代，直到测试通过
     • 约束：修复测试，而非业务逻辑（除非业务逻辑明显有问题）

7. 验证所有修复

   • 所有 Agent 完成后，再次运行完整测试套件
   • 确认所有测试均已通过

8. 必要时迭代

   • 如果仍有测试失败：返回第 5 步
   • 仅为剩余的失败项启动新 Agent
   • 持续迭代，直到通过率达到 100%

成功标准

• 所有测试均已通过 ✅
• 保持测试覆盖率
• 保留测试意图
• 业务逻辑未变更（除非发现错误）

Agent 指令模板

启动 Agent 时，请使用此模板：

The business logic has changed and test file {FILE_PATH} is now failing.

Your task:
1. Read the test file and understand what it's testing
2. Read TDD skill (if available) for best practices on writing tests.
3. Read @README.md for project context
4. Run the test: {TEST_COMMAND}
5. Analyze the failure - is it:
   - Test expectations outdated? → Fix test assertions
   - Test setup broken? → Fix test setup/mocks
   - Business logic bug? → Fix logic (rare case)
6. Fix the test and verify it passes
7. Iterate until test passes