test-fixing

修复测试

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

适用场景

• 明确要求修复测试（“修复这些测试”“让测试通过”）
• 报告测试失败（“测试失败了”“测试套件坏了”）
• 完成实现后希望测试通过
• 提到 CI/CD 测试失败

系统化方法

1. 初始测试运行

运行 make test，找出所有失败的测试。

分析输出，了解：

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

2. 智能错误分组

按以下方式对相似的失败进行分组：

• 错误类型：ImportError、AttributeError、AssertionError 等
• 模块/文件：同一文件导致的多个测试失败
• 根本原因：缺少依赖、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. 运行完整测试套件 → 全部通过 ✓