test-fixing

# 测试修复 使用智能分组策略系统地识别并修复所有失败的测试。 ## 何时使用 - 明确要求修复测试（“修复这些测试”、“让测试通过”） - 报告测试失败（“测试失败了”、“测试套件损坏”） - 完成实现并希望测试通过 - 提到由于测试导致的 CI/CD 失败 ## 系统化方法 ### 1. 初始测试运行 运行 `make test` 以识别所有失败的测试。 分析输出以获取： - 失败总数 - 错误类型和模式 - 受影响的模块/文件 ### 2. 智能错误分组 按以下方式对相似的失败进行分组： - **错误类型**：ImportError, AttributeError, AssertionError 等 - **模块/文件**：同一个文件导致多个测试失败 - **根本原因**：缺少依赖、API 变更、重构影响 按以下优先级排序： - 受影响的测试数量（影响最大的优先） - 依赖顺序（先修复基础设施，再修复功能） ### 3. 系统化修复流程 对于每一组（从影响最大的开始）： 1. **识别根本原因** - 阅读相关代码 - 使用 `git diff` 检查最近的变更 - 理解错误模式 2. **实施修复** - 使用编辑工具进行代码更改 - 遵循项目约定（参见 CLAUDE.md） - 进行最小化、有针对性的更改 3. **验证修复** - 运行该组的测试子集 - 使用 pytest 标记或文件模式： bash uv run pytest tests/path/to/test_file.py -v uv run pytest -k "pattern" -v - 确保该组通过后再继续 4. **进入下一组** ### 4. 修复顺序策略 **首先是基础设施：** - 导入错误 - 缺少依赖 - 配置问题 **然后是 API 变更：** - 函数签名变更 - 模块重组 - 重命名的变量/函数 **最后是逻辑问题：** - 断言失败 - 业务逻辑 Bug - 边界情况处理 ### 5. 最终验证 在所有组修复完成后： - 运行完整测试套件：`make test` - 验证没有回归问题 - 检查测试覆盖率保持不变 ## 最佳实践 - 一次修复一组 - 每次修复后运行针对性测试 - 使用 `git diff` 理解最近的变更 - 寻找失败中的模式 - 在当前组通过之前不要进入下一组 - 保持更改最小化且专注 ## 示例工作流 用户：“重构后测试失败了” 1. 运行 `make test` → 识别出 15 个失败 2. 分组错误： - 8 个 ImportError（模块重命名） - 5 个 AttributeError（函数签名变更）