test-fixing

修复测试

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

适用场景

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

系统化方法

1. 初始测试运行

阅读项目说明、依赖清单和 CI 配置，确定现有的测试命令。仅当 make test 目标存在且属于项目约定时才使用它。运行测试前，检查所需的 fixture 和服务；不要通过执行生产操作来获取基线结果。保留已有更改。

分析输出，了解：

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

2. 智能错误分组

按以下因素对相似失败进行分组：

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

按以下优先级处理分组：

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

3. 系统化修复流程

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

1. 确定根本原因

   • 阅读相关代码
   • 使用 git diff 检查近期更改
   • 理解错误模式

2. 实施修复

   • 使用主机提供的文件编辑工具修改代码
   • 遵循适用的项目说明和规范
   • 进行最小且有针对性的更改

3. 验证修复

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

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

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

4. 处理下一组

4. 修复顺序策略

先处理基础设施：

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

然后处理 API 变更：

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

最后处理逻辑问题：

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

5. 最终验证

修复所有分组后：

• 运行经过确认的项目完整测试命令
• 确认没有回归问题
• 确认测试覆盖率仍然完整

最佳实践

• 一次修复一个分组
• 每次修复后运行针对性测试
• 使用 git diff 了解近期更改
• 查找失败中的模式
• 当前分组通过后再处理下一组
• 保持更改最小且有针对性
• 不要为了让测试变绿而删除断言、跳过失败用例、降低覆盖率阈值或更改预期行为。只有在有证据表明产品约定已变更时，才更新测试。明确报告不可用的依赖、不稳定的失败以及未执行的检查。

工作流示例

用户：“重构后测试失败了”

1. 在已确认存在 make test 目标的仓库中运行该命令 → 发现 15 个失败
2. 对错误进行分组：
   • 8 个 ImportError（模块已重命名）
   • 5 个 AttributeError（函数签名已变更）
   • 2 个 AssertionError（逻辑缺陷）
3. 先修复 ImportError → 运行子集 → 验证
4. 修复 AttributeError → 运行子集 → 验证
5. 修复 AssertionError → 运行子集 → 验证
6. 运行完整测试套件 → 全部通过 ✓

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为环境专属验证、测试或专家审查的替代品。
• 如果缺少必要的输入、权限、安全边界或成功标准，请停止并请求澄清。