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
• リグレッションがないことを確認する
• テストカバレッジが維持されていることを確認する

ベストプラクティス

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

ワークフローの例

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

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