test-fixing
系統化修復失敗的測試
當重構或程式碼變更後測試失敗，此技能會按類型和根本原因對錯誤進行分組，然後按順序修復每個群組以使測試套件通過。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「test-fixing」。 The tests are failing after my recent refactor. I renamed several modules and now have 12 failing tests.
預期結果:
Running test suite to identify all failures...
Found 12 failing tests:
- 6 ImportErrors (module renaming impact)
- 4 AttributeErrors (function signature changes)
- 2 AssertionErrors (logic changes)
Prioritizing by impact:
1. ImportErrors (6 tests) - fixing first
2. AttributeErrors (4 tests)
3. AssertionErrors (2 tests)
Starting with ImportError group: analyzing module structure...
正在使用「test-fixing」。 Help me fix the failing tests in the API module. They started failing after I updated the dependencies.
預期結果:
Running focused test on API module: pytest tests/api/ -v
Grouping failures by error type:
- 3 ImportError (missing dependency)
- 2 AssertionError (API response format changed)
Following fix order strategy:
1. Fix infrastructure: add missing dependency
2. Fix logic: update assertion for new response format
Verifying each fix with targeted test runs...
安全審計
安全All static findings are false positives. The skill is documentation-only (SKILL.md) with no executable code. The detected 'external_commands' are markdown examples of CLI commands, not actual shell executions. The 'weak cryptographic algorithm' finding is a scanner misidentification with no cryptographic code present.
品質評分
你能建構什麼
重構後修復測試
在重命名跨程式碼庫的模組或函數後，此技能可幫助識別所有受影響的測試失敗，按類型分組，並系統化地修復每個群組。
處理 CI/CD 測試失敗
當 CI 管道因測試錯誤而失敗時，使用此技能來分組失敗、理解根本原因，並在重試管道之前系統化地修復。
除錯多個測試失敗
當執行大型測試套件顯示許多失敗時，此技能有助於根據依賴順序和影響程度優先修復哪些問題。
試試這些提示
測試在我最近的變更後失敗了。請使用測試修復技能幫助我修復它們。先執行測試套件以查看所有失敗。
我重構了我的程式碼庫，現在有 15 個測試失敗。使用智慧錯誤分組來分類這些失敗並按正確順序修復。先執行 make test 查看所有失敗。
我的 CI 管道因測試錯誤而失敗。使用測試修復技能來識別每個失敗的根本原因。優先處理基礎設施問題，如匯入錯誤和缺失的依賴項。
我的 auth 模組測試中有 5 個 ImportError 失敗。先修復這些特定的失敗，驗證它們通過，然後我們再處理其他錯誤群組。
最佳實務
- 在每個修復後執行聚焦的測試子集，以驗證變更有效，然後再移至下一個群組
- 先修復基礎設施問題（匯入、依賴、配置）再修復邏輯錯誤，以獲得更清晰的錯誤狀態
- 使用 git diff 了解最近變更的內容，並識別測試失敗的根本原因
- 保持變更最小且專注 - 一次修復一個問題，而不是大量變更
避免
- 一次性修復所有測試而不執行子集 - 這使得很難識別哪個修復解決了哪個錯誤
- 忽略基礎設施錯誤而先嘗試修復邏輯錯誤 - 匯入失敗會掩蓋真正的問題
- 進行大規模的全面變更而非針對性的修復 - 增加引入新錯誤的風險
- 跳過最終的完整測試套件執行 - 可能會錯過修復過程中引入的回歸問題