kscz0000 测试修复
使用智能分组策略系统性地识别并修复所有失败的测试。
何时使用
- 明确要求修复测试（"修复这些测试"、"让测试通过"）
- 报告测试失败（"测试失败了"、"测试套件坏了"）
- 完成实现后希望测试通过
- 提到 CI/CD 因测试而失败
系统性方法
1. 初始测试运行
运行 make test 识别所有失败的测试。
分析输出以获取：
- 失败总数
- 错误类型和模式
- 受影响的模块/文件
2. 智能错误分组
按以下方式对相似失败进行分组：
- 错误类型：ImportError、AttributeError、AssertionError 等
- 模块/文件：同一文件导致多个测试失败
- 根本原因：缺少依赖、API 变更、重构影响
按以下方式确定分组优先级：
- 受影响的测试数量（优先处理影响最大的）
- 依赖顺序（先修复基础设施，再修复功能）
3. 系统性修复流程
对于每个分组（从影响最大的开始）：
识别根本原因
- 阅读相关代码
- 使用
git diff检查最近的变更 - 理解错误模式
实施修复
- 使用 Edit 工具进行代码更改
- 遵循项目约定（参见 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 个 ImportError（模块重命名）
- 5 个 AttributeError（函数签名变更）
- 2 个 AssertionError（逻辑错误）
- 先修复 ImportError → 运行子集 → 验证
- 修复 AttributeError → 运行子集 → 验证
- 修复 AssertionError → 运行子集 → 验证
- 运行完整套件 → 全部通过 ✓
局限性
- 仅当任务明确匹配上述范围时使用此技能。
- 不要将输出作为环境特定验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。