企业官网建设流程全解析

name: test-fixing
description: “Systematically identify and fix all failing tests using smart grouping strategies. Use when explicitly asks to fix tests (“fix these tests”, “make tests pass”), reports test failures (“tests are failing”, “test suite is broken”), or completes implementation and wants tests passing.”
risk: safe
source: community
date_added: “2026-02-27”

Test Fixing（测试修复）

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

何时使用

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

系统化方法

1. 初始测试运行

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

分析输出：

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

2. 智能错误分组

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

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

按以下方式对组进行优先级排序：

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

3. 系统化修复流程

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

1. 识别根本原因

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

2. 实施修复

   • 使用编辑工具进行代码更改
   • 遵循项目约定（参见 CLAUDE.md）
   • 做最小、聚焦的更改

3. 验证修复

   • 运行此组的测试子集
   • 使用 pytest 标记或文件模式：

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

   • 确保该组通过后再继续

4. 移到下一个组

4. 修复顺序策略

基础设施优先：

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

然后是 API 更改：

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

最后是逻辑问题：

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

5. 最终验证

所有组修复后：

• 运行完整测试套件：make test
• 验证没有回归
• 检查测试覆盖率保持不变

最佳实践

• 一次修复一个组
• 每次修复后运行聚焦的测试
• 使用git diff理解最近的更改
• 在失败中寻找模式
• 在当前组通过之前不要移到下一组
• 保持更改最小且聚焦

示例工作流

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

1. 运行make test→ 识别出 15 个失败
2. 对错误分组：
   • 8 个 ImportErrors（模块重命名）
   • 5 个 AttributeErrors（函数签名更改）
   • 2 个 AssertionErrors（逻辑 bug）
3. 先修复 ImportErrors → 运行子集 → 验证
4. 修复 AttributeErrors → 运行子集 → 验证
5. 修复 AssertionErrors → 运行子集 → 验证
6. 运行完整套件 → 全部通过 ✓

局限性

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