テスト修正

スマートなグループ化戦略を使用して、失敗しているすべてのテストを体系的に特定し修正します。

使用時期

• テスト修正を明示的に依頼される場合（「このテストを修正して」、「テストを成功させて」）
• テスト失敗を報告される場合（「テストが失敗している」、「テストスイートが壊れている」）
• 実装完了後にテストの成功を希望する場合
• テストが原因で CI/CD が失敗している場合

体系的なアプローチ

1. 初期テスト実行

make test を実行してすべての失敗したテストを特定します。

出力を以下の項目について分析します：

• 失敗の総数
• エラー型とパターン
• 影響を受けるモジュール/ファイル

2. スマートなエラーグループ化

同様の失敗を以下でグループ化します：

• エラー型: ImportError、AttributeError、AssertionError など
• モジュール/ファイル: 複数のテスト失敗を引き起こす同一ファイル
• 根本原因: 欠落している依存関係、API の変更、リファクタリングの影響

グループを以下の優先度で優先付けします：

• 影響を受けるテストの数（最も影響の大きいものから）
• 依存関係の順序（インフラストラクチャを機能の前に修正）

3. 体系的な修正プロセス

各グループについて（最も影響の大きいものから開始）：

1. 根本原因を特定する

   • 関連するコードを読む
   • git diff で最近の変更を確認する
   • エラーパターンを理解する

2. 修正を実装する

   • Edit ツールでコード変更を行う
   • プロジェクト規約に従う（CLAUDE.md を参照）
   • 最小限で焦点を絞った変更を行う

3. 修正を検証する

   • このグループのテストのサブセットを実行する
   • pytest マーカーまたはファイルパターンを使用：

     uv run pytest tests/path/to/test_file.py -v
     uv run pytest -k "pattern" -v
     

   • 次に進む前にグループが成功することを確認する

4. 次のグループに移行する

4. 修正の順序戦略

インフラストラクチャから優先:

• インポートエラー
• 欠落している依存関係
• 設定の問題

その次に API の変更:

• 関数シグネチャの変更
• モジュール再編成
• 変数/関数の名前変更

最後に、ロジックの問題:

• アサーション失敗
• ビジネスロジックバグ
• エッジケースの処理

5. 最終検証

すべてのグループが修正された後：

• 完全なテストスイートを実行: make test
• 回帰がないことを確認
• テストカバレッジが維持されていることを確認

ベストプラクティス

• 一度に 1 つのグループを修正する
• 各修正後に焦点を絞ったテストを実行する
• git diff を使用して最近の変更を理解する
• 失敗のパターンを探す
• 現在のグループが成功するまで次に進まない
• 変更を最小限で焦点を絞ったものにする

ワークフロー例

ユーザー: 「リファクタ後にテストが失敗しています」

1. make test を実行 → 15 個の失敗を特定
2. エラーをグループ化：
   • 8 個の ImportError（モジュール名変更）
   • 5 個の AttributeError（関数シグネチャ変更）
   • 2 個の AssertionError（ロジックバグ）
3. ImportError を最初に修正 → サブセットを実行 → 検証
4. AttributeError を修正 → サブセットを実行 → 検証
5. AssertionError を修正 → サブセットを実行 → 検証
6. 完全なスイートを実行 → すべて成功 ✓

制限事項

• このスキルは、タスクが上記で説明されたスコープと明確に一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家のレビューの代わりと考えないでください。
• 必要な入力、権限、安全境界、または成功基準が欠落している場合は、停止して明確化を求めてください。