test-fixing

テスト修正

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

使用するタイミング

• テストの修正を明示的に依頼された場合（「これらのテストを修正して」「テストを通るようにして」など）
• テストの失敗を報告された場合（「テストが失敗している」「テストスイートが壊れている」など）
• 実装を完了し、テストを通したい場合
• テストが原因で 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. 修正順序の戦略

まずインフラ：

• Import エラー
• 依存関係の欠落
• 設定の問題

次に API の変更：

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

最後にロジックの問題：

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

5. 最終検証

すべてのグループを修正した後：

• 完全なテストスイートを実行する：make test
• リグレッションがないことを確認する
• テストカバレッジが維持されていることを確認する

ベストプラクティス

• 一度に一つのグループを修正する
• 各修正の後に、的を絞ったテストを実行する
• git diff を使って最近の変更を把握する
• 失敗のパターンを探す
• 現在のグループが通るまで次のグループに進まない
• 変更は最小限かつ的を絞ったものに保つ

ワークフローの例

ユーザー：「リファクタリングの後、テストが失敗しています」

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