名称: 测试修复 描述: 运行测试并使用智能错误分组系统性修复所有失败的测试。当用户要求修复测试、提及测试失败、运行测试套件并出现失败，或请求使测试通过时使用。
测试修复
系统性识别和修复所有失败的测试，使用智能分组策略。
何时使用
- 明确要求修复测试（“修复这些测试”，“使测试通过”）
- 报告测试失败（“测试失败”，“测试套件损坏”）
- 完成实现并希望测试通过
- 提及由于测试导致的CI/CD失败
系统方法
1. 初始测试运行
运行 make test 以识别所有失败的测试。
分析输出：
- 失败总数
- 错误类型和模式
- 受影响的模块/文件
2. 智能错误分组
按以下方式分组相似失败：
- 错误类型：ImportError, AttributeError, AssertionError 等
- 模块/文件：导致多个测试失败的同一文件
- 根本原因：缺失依赖项、API更改、重构影响
按以下优先级分组：
- 受影响测试数量（最高影响优先）
- 依赖顺序（先修复基础设施后修复功能）
3. 系统性修复过程
对于每个组（从最高影响开始）：
-
识别根本原因
- 阅读相关代码
- 使用
git diff检查最近更改 - 理解错误模式
-
实施修复
- 使用编辑工具进行代码更改
- 遵循项目约定（见 CLAUDE.md）
- 进行最小化、有针对性的更改
-
验证修复
- 为此组运行测试子集
- 使用 pytest 标记或文件模式：
uv run pytest tests/path/to/test_file.py -v uv run pytest -k "pattern" -v - 确保组通过后再继续
-
移动到下一组
4. 修复顺序策略
基础设施优先：
- 导入错误
- 缺失依赖项
- 配置问题
然后API更改：
- 函数签名更改
- 模块重组
- 重命名变量/函数
最后逻辑问题：
- 断言失败
- 业务逻辑错误
- 边缘情况处理
5. 最终验证
所有组修复后：
- 运行完整测试套件：
make test - 验证无回归
- 检查测试覆盖率保持不变
最佳实践
- 一次修复一个组
- 每次修复后运行针对性测试
- 使用
git diff理解最近更改 - 寻找失败模式
- 在当前组通过前不要移动到下一组
- 保持更改最小化和有针对性的
示例工作流
用户：“重构后测试失败”
- 运行
make test→ 识别15个失败 - 分组错误：
- 8个ImportErrors（模块重命名）
- 5个AttributeErrors（函数签名更改）
- 2个AssertionErrors（逻辑错误）
- 首先修复ImportErrors → 运行子集 → 验证
- 修复AttributeErrors → 运行子集 → 验证
- 修复AssertionErrors → 运行子集 → 验证
- 运行完整套件 → 全部通过 ✓