name: test-fixing description: "运行测试并使用智能错误分组系统性地修复所有失败测试。当用户要求修复失败测试、提及测试失败、运行测试套件出现失败，或要求让测试通过时使用" version: "1.0.0"

测试修复

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

使用时机

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

系统方法

1. 初次运行测试

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

分析输出，关注：

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

2. 智能错误分组

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

• 错误类型：ImportError、AttributeError、AssertionError 等
• 模块/文件：同一文件导致多个测试失败
• 根因：缺失依赖、API 变更、重构影响

  小葱技能站7w4.net每天更新，海量AI技能等你发现。

按以下优先级排序分组：

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

3. 系统性修复流程

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

1. 定位根因

2. 阅读相关代码

3. 通过 git diff 查看近期变更

4. 理解错误模式

5. 实施修复

6. 使用 Edit 工具进行代码变更

7. 遵循项目约定（参见 CLAUDE.md）

8. 做最小且聚焦的改动

9. 验证修复

10. 运行该分组的测试子集

11. 使用 pytest 标记或文件模式： bash uv run pytest tests/path/to/test_file.py -v uv run pytest -k "pattern" -v

12. 确认该分组通过后再继续

13. 进入下一组

4. 修复顺序策略

先基础设施：

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

再 API 变更：

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

最后逻辑问题：

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

5. 最终验证

所有分组修复完成后：

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

最佳实践

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

示例工作流

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

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

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