mcpField
T
test-and-fix

test-and-fix

github.com/timlai666テスト・品質042 回インストール1 日前に更新
リポジトリ

test-and-fix について

test-and-fix は、開発者やコーディングエージェント向けのソフトウェアテストスキルです。変更の分析からテスト計画と実行、回帰テストを伴う修正までを手順化します。

主な機能

  1. 01変更と呼び出し元の分析
  2. 02動作に基づくテスト計画
  3. 03テスト実行と結果の記録
  4. 04回帰テスト付きの最小修正
  5. 05検証不足の報告

活用シーン

  1. 01変更後の API やライブラリのテスト
  2. 02CLI 引数とファイルへの影響確認
  3. 03Web UI の操作確認
  4. 04テスト失敗の調査とカバー

インストール

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

$npx skills add https://github.com/timlai666/skills --skill test-and-fix

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

詳細

前文

ユーザーが指定したテスト範囲とコマンド、プロジェクトの指示、テスト設定、関連するソースファイルを確認します。期待される動作の確認に役立つ場合は、プロジェクトの既存のリリース記録やタスク記録を使用します。

対象を特定します。Web UI、API、コマンドラインツール、ライブラリ、その他の成果物のいずれかです。テストはベースブランチを含む現在のブランチで実行できます。編集する前に、既存の変更を確認します。

フェーズ 1 — 変更内容を分析する

まず、提示された範囲を確認します。変更をテストする際は、関連するステージ済み、未ステージ、またはコミット済みの差分を調べ、呼び出し元や利用側を追跡します。タスクまたはリポジトリの設定から比較対象の参照先を特定し、比較に最新のリモート情報が必要な場合に限りフェッチします。

影響を受ける動作を整理します。

  • Web UI：ページ、コンポーネント、操作、レンダリング状態。
  • API：エンドポイント、認証、入力、応答、エラー。
  • CLI：引数、入出力、終了コード、ファイルへの影響。
  • ライブラリ：公開関数、呼び出し元、戻り値、エッジケース。

テストに実行中のサービスが必要な場合は、プロジェクトの設定、ドキュメント、または既存プロセスの出力から起動コマンドとアドレスを確認します。タスクで許可されている範囲内で、必要なローカルサービスを起動します。利用可能な情報から確認できない必須事項についてのみ質問します。

フェーズ 2 — テスト計画を作成する

影響を受ける動作ごとに、期待される結果、テスト方法、優先度を特定します。関連する正常系、無効な入力、空の入力、失敗のケースを含めます。software-engineering-guidelines のテスト戦略に従い、プロジェクトで既に使われているテストコマンドと検証要件を使用します。

計画をリクエストおよび関連するタスク記録と照合します。不一致がある場合は、テスト範囲を黙って変更するのではなく、期待される動作を確認します。

フェーズ 3 — テストを実行する

選択したテストを使って、フェーズ 2 の計画を実行します。Web UI の変更では、実行中のアプリケーションで、影響を受けるレンダリングと操作を確認します。プロジェクトの規則に従い、テストスイート全体を実行します。

各テストについて、次のように記録します。

  • 合格 — 検証した内容を説明します
  • 不合格 — 正確な症状と根拠を示します
  • 想定外 — 計画していなかったことを記録します

フェーズ 4 — 修正ループ

失敗ごとに、まず根本原因を特定します。テスト対象の変更と証拠から特定できない場合は、investigate を実行します。

  1. 修正がないと失敗し、修正があると成功する回帰テストを追加または更新します。タイミングについては software-engineering-guidelines に従います。大規模または高リスクな変更はテストファーストで進め、小規模で局所的かつ低リスクな修正では、実装の前または直後にテストを追加できます。
  2. 最小限の修正を行い、失敗したケースと関連する回帰チェックを再実行します。
  3. ユーザーの指示とプロジェクトの慣例に従ってコミットします。コミットの取り決めが指定されていない場合は、元の既定のとおり、修正を単独でコミットし、その後、回帰テストを別途コミットします。テストを先に書くことと、後でコミットすることは別々の判断です。意図した変更のみをステージし、無関係な作業は保持します。

修正したすべてのバグに回帰テストを追加します。検証できなかった点は明示して報告します。

報告

## Test Report [feature/branch] [date]

### Summary
Tests run: N | Passed: N | Failed: N | Fixed: N (with regression tests)

### Changes tested
- [target/behavior] — [result]

### Bugs found & fixed
1. [description] — file:line — regression test: [test name]

### Issues found (not yet fixed)
1. [P0/P1/P2] [description] — blocking: [yes/no]

### Regression tests added
- [test file]: [test names]

### Recommendation
[SHIP / FIX FIRST / INVESTIGATE]

テストが存在しない場合のテストフレームワークの導入

動作を検証できる組み込み言語ツール、既存スクリプト、または小規模で再現可能なテストがないか確認します。必要な機能を補える場合はテストフレームワークを使用します。タスクで許可されている範囲内で、導入前に依存関係とセットアップへの影響を説明します。

再現可能なチェックでは、実際の動作を実行し、修正がない状態でバグを検出できる必要があります。検証を続けられない場合は、未検証の修正を完了扱いにせず、不足している機能を報告します。上記のコミットの取り決めに従います。既定の取り決めを適用する場合、テストフレームワークのセットアップは別途コミットします。

コメント

Markdown 対応