mcpField
T
test-fixing

test-fixing

github.com/sickn33テスト・品質48.7k635 回インストール今日更新
リポジトリ

test-fixing について

失敗したテストをエラーごとに分類し、対象を絞った検証を通じて診断・修正するスキルです。テストスイートやテスト関連の CI 障害に取り組む開発者向けで、期待値を保つ最小限の修正を重視します。

主な機能

  1. 01確認済みのプロジェクトテストコマンドを実行
  2. 02エラー・ファイル・原因ごとに失敗を分類
  3. 03基盤や API の問題を優先
  4. 04対象を絞った最小限の修正
  5. 05段階的に検証し全テストを実行

活用シーン

  1. 01コード変更後に失敗したテストスイートを調査
  2. 02テストに起因する CI 障害に対処
  3. 03全テストの前に対象テストで修正を検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill test-fixing

インストール後、Claude Code で/test-fixingを入力して読み込まれたか確認します。

詳細

テストの修正

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

使用する場面

  • テストの修正を明示的に依頼された場合(「このテストを修正して」「テストを通るようにして」)
  • テストの失敗が報告された場合(「テストが失敗している」「テストスイートが壊れている」)
  • 実装を終え、テストを通したい場合
  • テストに起因する CI/CD の失敗について言及された場合

体系的なアプローチ

1. 最初のテスト実行

プロジェクトの既存のテストコマンドを特定するため、プロジェクトの指示、依存関係マニフェスト、CI 設定を読みます。make test ターゲットが存在し、それがプロジェクトで定められたコマンドである場合に限り、make test を使います。実行前にフィクスチャやサービスの要件を確認し、ベースラインを取得するために本番環境の操作を実行しないでください。既存の変更は保持します。

出力を分析し、次の点を確認します。

  • 失敗の合計数
  • エラーの種類とパターン
  • 影響を受けるモジュール/ファイル
2. エラーのスマートなグループ化

類似する失敗を次の観点でグループ化します。

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

次の点を考慮して、優先順位を付けます。

  • 影響を受けるテストの数(影響が大きいものを優先)
  • 依存関係の順序(機能より先にインフラストラクチャを修正)
3. 体系的な修正プロセス

各グループについて、影響が大きいものから順に、次の手順を実行します。

  1. 根本原因を特定する

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

    • コードの変更には、ホストで利用できるファイル編集ツールを使用する
    • 該当するプロジェクトの指示や規約に従う
    • 変更は最小限かつ対象を絞る
  3. 修正を検証する

    • このグループのテストの一部を実行する
    • pytest のマーカーやファイルパターンを使う:
      uv run pytest tests/path/to/test_file.py -v
      uv run pytest -k "pattern" -v
      
    • 次に進む前に、グループ内のテストが通ることを確認する
  4. 次のグループに進む

4. 修正の順序

まずインフラストラクチャ:

  • インポートエラー
  • 依存関係の不足
  • 設定の問題

次に API の変更:

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

最後にロジックの問題:

  • アサーションの失敗
  • ビジネスロジックの不具合
  • エッジケースへの対応
5. 最終確認

すべてのグループを修正した後、次を実施します。

  • プロジェクトで検証済みの完全なテストコマンドを実行する
  • リグレッションがないことを確認する
  • テストカバレッジが維持されていることを確認する

ベストプラクティス

  • 一度に一つのグループを修正する
  • 修正のたびに対象を絞ったテストを実行する
  • git diff で最近の変更を把握する
  • 失敗に共通するパターンを探す
  • 現在のグループが通るまで次に進まない
  • 変更は最小限かつ対象を絞る
  • テストを通すためだけに、アサーションを削除したり、失敗するケースをスキップしたり、カバレッジのしきい値を下げたり、期待される動作を変更したりしないでください。テストの更新には、製品の契約が変更されたという根拠が必要です。利用できない依存関係、不安定な失敗、実行していない確認項目は、明示的に報告してください。

ワークフローの例

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

  1. 検証済みの make test ターゲットがあるリポジトリで make test を実行する → 15 件の失敗を特定
  2. エラーをグループ化する:
    • ImportError が 8 件(モジュールの名前変更)
    • AttributeError が 5 件(関数シグネチャの変更)
    • AssertionError が 2 件(ロジックの不具合)
  3. まず ImportError を修正する → 対象を絞ったテストを実行する → 検証する
  4. AttributeError を修正する → 対象を絞ったテストを実行する → 検証する
  5. AssertionError を修正する → 対象を絞ったテストを実行する → 検証する
  6. テストスイート全体を実行する → すべて成功 ✓

制限事項

  • このスキルは、タスクが上記の範囲に明確に該当する場合にのみ使用してください。
  • 出力を、環境固有の検証、テスト、専門家によるレビューの代わりにしないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。

コメント