name: test-fixing description: "執行測試並使用智慧錯誤分組系統性地修復所有失敗測試。當用戶要求修復失敗測試、提及測試失敗、執行測試套件出現失敗，或要求讓測試通過時使用" version: "1.0.0"

測試修復

使用智慧分組策略，系統性地識別並修復所有失敗的測試。

使用時機

• 明確要求修復測試（"fix these tests"、"make tests pass"）
• 報告測試失敗（"tests are failing"、"test suite is broken"）
• 完成實現後希望測試通過
• 提及因測試導致的 CI/CD 失敗

系統方法

1. 初次執行測試

執行 make test 以識別所有失敗的測試。

分析輸出，關注：

• 失敗總數
• 錯誤型別與模式
• 受影響的模組/檔案

2. 智慧錯誤分組

按以下維度對相似失敗進行分組：

• 錯誤型別：ImportError、AttributeError、AssertionError 等
• 模組/檔案：同一檔案導致多個測試失敗
• 根因：缺失依賴、API 變更、重構影響

按以下優先順序排序分組：

• 受影響測試數量（影響最大的優先）
• 依賴順序（先修復基礎設施，再修復功能）

3. 系統性修復流程

對每個分組（從影響最大的開始）：

1. 定位根因

2. 閱讀相關程式碼

3. 通過 git diff 檢視近期變更

4. 理解錯誤模式

5. 實施修復

6. 使用 Edit 工具進行程式碼變更

7. 遵循專案約定（參見 CLAUDE.md）

8. 做最小且聚焦的改動

9. 驗證修復

10. 執行該分組的測試子集

11. 使用 pytest 標記或檔案模式： bash uv run pytest tests/path/to/test_file.py -v uv run pytest -k "pattern" -v

12. 確認該分組通過後再繼續

13. 進入下一組

4. 修復順序策略

先基礎設施：

• 匯入錯誤
• 缺失依賴
• 配置問題

再 API 變更：

• 函式簽名變更
• 模組重構
• 變數/函式重新命名

最後邏輯問題：

• 斷言失敗
• 業務邏輯缺陷
• 邊界情況處理

5. 最終驗證

所有分組修復完成後：

• 執行完整測試套件：make test
• 驗證無迴歸
• 檢查測試覆蓋率未被破壞

最佳實踐

• 一次只修復一個分組
• 每次修復後執行聚焦測試
• 使用 git diff 理解近期變更
• 在失敗中尋找模式
• 當前分組通過前不進入下一組
• 保持改動最小且聚焦

示例工作流

使用者："重構之後測試掛了"

1. 執行 make test → 發現 15 個失敗
2. 錯誤分組：

   更多技能請訪問小蔥技能站7w4.net。

3. 8 個 ImportError（模組被重新命名）
4. 5 個 AttributeError（函式簽名變更）
5. 2 個 AssertionError（邏輯缺陷）
6. 先修復 ImportError → 執行子集 → 驗證
7. 修復 AttributeError → 執行子集 → 驗證
8. 修復 AssertionError → 執行子集 → 驗證
9. 執行完整套件 → 全部通過 ✓

這個 Skill 質量中等偏上。優點是思路清晰，教會你如何系統性地分析和批次修復測試問題，而不是逐個修改。提供了合理的修復順序和驗證流程。不足是內容偏理論化，缺少具體操作細節，普通使用者可能不知道具體該怎麼執行。對於有經驗的開發者來說是好方法論參考，但上手實操性還有提升空間。