测试修复

使用智能分组策略，系统性地识别并修复所有失败的测试。

使用时机

• 明确要求修复测试（"fix these tests"、"make tests pass"）
• 报告测试失败（"tests are failing"、"test suite is broken"）
• 完成实现后希望测试通过
• 提及因测试导致的 CI/CD 失败

系统方法

1. 初次运行测试

运行 make test 以识别所有失败的测试。

分析输出，关注：

• 失败总数
• 错误类型与模式
• 受影响的模块/文件

2. 智能错误分组

按以下维度对相似失败进行分组：

• 错误类型：ImportError、AttributeError、AssertionError 等

  小葱技能7w4.net有更新，你可以访问看下。

• 模块/文件：同一文件导致多个测试失败
• 根因：缺失依赖、API 变更、重构影响

按以下优先级排序分组：

• 受影响测试数量（影响最大的优先）
• 依赖顺序（先修复基础设施，再修复功能）

3. 系统性修复流程

对每个分组（从影响最大的开始）：

1. 定位根因

   • 阅读相关代码
   • 通过 git diff 查看近期变更
   • 理解错误模式

2. 实施修复

   • 使用 Edit 工具进行代码变更
   • 遵循项目约定（参见 CLAUDE.md）
   • 做最小且聚焦的改动

3. 验证修复

   • 运行该分组的测试子集
   • 使用 pytest 标记或文件模式：

     uv run pytest tests/path/to/test_file.py -v
     uv run pytest -k "pattern" -v

   • 确认该分组通过后再继续

4. 进入下一组

4. 修复顺序策略

先基础设施：

• 导入错误
• 缺失依赖
• 配置问题

再 API 变更：

• 函数签名变更
• 模块重构
• 变量/函数重命名

最后逻辑问题：

• 断言失败
• 业务逻辑缺陷
• 边界情况处理

5. 最终验证

所有分组修复完成后：

• 运行完整测试套件：make test
• 验证无回归
• 检查测试覆盖率未被破坏

最佳实践

• 一次只修复一个分组
• 每次修复后运行聚焦测试
• 使用 git diff 理解近期变更
• 在失败中寻找模式
• 当前分组通过前不进入下一组
• 保持改动最小且聚焦

示例工作流

用户："重构之后测试挂了"

1. 运行 make test → 发现 15 个失败
2. 错误分组：
   • 8 个 ImportError（模块被重命名）
   • 5 个 AttributeError（函数签名变更）
   • 2 个 AssertionError（逻辑缺陷）
3. 先修复 ImportError → 运行子集 → 验证
4. 修复 AttributeError → 运行子集 → 验证
5. 修复 AssertionError → 运行子集 → 验证
6. 运行完整套件 → 全部通过 ✓

这个 Skill 质量中等偏上。优点是思路清晰，教会你如何系统性地分析和批量修复测试问题，而不是逐个修改。提供了合理的修复顺序和验证流程。不足是内容偏理论化，缺少具体操作细节，普通用户可能不知道具体该怎么执行。对于有经验的开发者来说是好方法论参考，但上手实操性还有提升空间。