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. 运行完整测试套件 → 全部通过 ✓