# Test Fixing

> 使用智能分组策略系统性地识别并修复所有失败的测试。当用户明确要求修复测试（"修复这些测试"、"让测试通过"）、报告测试失败（"测试失败了"、"测试套件坏了"）、完成实现后希望测试通过，或提到 CI/CD 因测试而失败时使用。

- Skill: `kscz0000/test-fixing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/test-fixing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/test-fixing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/test-fixing

---


# 测试修复

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

## 何时使用

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

## 系统性方法

### 1. 初始测试运行

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

分析输出以获取：

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

### 2. 智能错误分组

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

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

按以下方式确定分组优先级：

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

### 3. 系统性修复流程

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

1. **识别根本原因**

   - 阅读相关代码
   - 使用 `git diff` 检查最近的变更
   - 理解错误模式

2. **实施修复**

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

3. **验证修复**

   - 运行该分组的测试子集
   - 使用 pytest 标记或文件模式：
     ```bash
     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. 运行完整套件 → 全部通过 ✓

## 局限性

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