verify-test-cases

ベースブランチから分岐して以降に変更されたすべてのテストファイルについて、テストケースの品質と正確性を検証します。

使用方法：

• /verify-test-cases - ベースブランチから分岐して以降に変更されたテストファイルを検証します

手順：

1. ベースブランチを特定します：

   • カレントディレクトリに .agent ファイルがあるか確認します
   • ファイルがある場合は内容を読み、baseBranch=<value> の行を探してベースブランチを抽出します
   • .agent ファイルがない場合、または baseBranch キーがない場合は、デフォルトで main を使用します

2. 分岐以降に変更されたテストファイルを特定します：

   • git diff --name-only <base-branch>...HEAD を実行し、ベースブランチから分岐して以降に変更されたすべてのファイルを取得します
   • 一般的なパターンを使ってテストファイルを絞り込みます：
     • *.test.*、*.spec.*（JS/TS）
     • test_*.py、*_test.py（Python）
     • *_test.go（Go）
     • *_test.rs、tests/ 配下のファイル（Rust）
     • __tests__/、test/、tests/、spec/ ディレクトリ配下のファイル
   • テストファイルが変更されていない場合は、ユーザーに伝えて終了します

3. チームでテストファイルを分析します：

   複数のエージェントを並行して起動し、それぞれがテストファイルを独立して分析します。

   a) テストファイル数に応じてチームの規模を決定します：

   • テストファイルが1～2個の場合 → 直接分析します（チームは不要です）
   • テストファイルが3～5個の場合 → レビュアーエージェントを2つ起動します
   • テストファイルが6個以上の場合 → レビュアーエージェントを3つ起動します

   b) チームを起動する場合：

   • 名前を verify-tests にして TeamCreate を使用します
   • レビュアーごとに1つのタスクを作成するため、TaskCreate を使用します。タスク名は「テストファイルをレビュー：<file1>、<file2>、...」とします
   • 可能であれば、同じソースモジュールをテストするファイルをまとめて、テストファイルをレビュアーに割り当てます
   • チーム名を指定し、run_in_background: true を設定して、Task ツール（subagent_type: general-purpose）でレビュアーを起動します
   • 各レビュアーには以下を渡します：
     • 分析対象のテストファイル一覧
     • コンテキストを把握するため、テスト対象のソースファイルも読むよう指示します
     • 以下の手順4と5の検証チェックリスト全文
   • レビュアーはタスクを完了としてマークし、調査結果をチームリードに伝える必要があります
   • すべてのレビュアーが完了するまで待ってから、結果を集約します

   c) 直接分析する場合（ファイルが1～2個）：

   • 手順4と5に従って、自分でテストファイルを読み、分析します

4. テストケースが妥当か検証します： 各テストファイルについて、以下を確認します：

   a. テストの説明が動作と一致していること：

   • テスト名や説明が、テスト対象を正確に表している
   • テスト本体が、名前に記載された内容を実際にテストしている

   b. アサーションに意味があること：

   • 結果を検証せずにコードを実行するだけではなく、実際のアサーションがある
   • アサーションが適切な内容を検証している（すべてに対して単に toBeTruthy() を使っていない）
   • 適切な場合、エッジケースや境界条件が網羅されている

   c. テストのセットアップが正しいこと：

   • モックやスタブがテスト内容に即している
   • テスト用のフィクスチャやデータが現実的である
   • セットアップ／ティアダウンで状態が適切に初期化・クリーンアップされている

   d. テストが独立していること：

   • テストの実行順序に依存していない
   • 共有状態がテスト間に漏れていない

   e. テストがソースコードに対応していること：

   • 実際の関数シグネチャと動作をテストしている
   • 古くなったAPIや存在しないAPIをテストしていない

5. 重複を確認します： 各テストファイル内、および変更されたすべてのテストファイル間で、以下を確認します：

   a. 完全な重複：

   • テスト本体が同一またはほぼ同一のテスト
   • 変更されていないテストのコピー＆ペースト

   b. 論理的な重複：

   • 異なるテストで、まったく同じ動作を検証しているもの
   • 検証内容が大幅に重複しているテスト

   c. 冗長なアサーション：

   • 別々のテスト内で同じ内容を確認する複数のアサーション
   • 他のテストの内容を完全に包含しているテスト

6. 調査結果を報告します：

   チームを使用した場合は、すべてのレビュアーの調査結果を集約し、チームを解散します（各レビュアーに shutdown_request を送り、その後 TeamDelete を実行します）。 次の形式で出力してください。

## Test Verification Report

### Files Analyzed
- `path/to/file.test.ts` (N tests)
- `path/to/other.spec.js` (N tests)

### Issues Found

#### Nonsensical / Incorrect Tests
- **file.test.ts:42** `"should handle empty input"` - Test passes a non-empty string, contradicting its description
- **file.test.ts:67** `"should return user"` - No assertion on the return value

#### Duplicate Tests
- **file.test.ts:30** and **file.test.ts:55** - Both test the same "valid email" scenario with identical logic
- **other.spec.js:12** and **other.spec.js:40** - Logically equivalent: both verify default config values

#### Missing Coverage
- `createUser()` has no test for the error/rejection path
- Edge case: empty array input is not tested for `processItems()`

### Summary
- Total test files analyzed: N
- Total test cases reviewed: N
- Issues found: N
- Duplicates found: N
- Verdict: PASS / NEEDS ATTENTION

7. カバレッジゲート（テストケースの変更が確定した後に必ず実施）：

   • テストケースの作業が完了したことをユーザーが明示的に確認するまで待ちます。確認方法は、提案した編集を適用した後にユーザーが承認する、自分で変更を適用したとユーザーが確認する、またはレポート上テストの変更は不要で続行してよいとユーザーが確認する、のいずれかです。
   • カバレッジコマンドを選択します（リポジトリのルート）。package.json がない場合は、このワークスペースではカバレッジを実行できないことをユーザーに伝え、レポートの後に停止します。
   • Node.js プロジェクト： package.json の scripts と依存関係（dependencies／devDependencies／peerDependencies）を読み取ります。
     1. test:coverage スクリプトがある場合は、npm run test:coverage を使用します。
     2. それ以外で、プロジェクトが Vitest を使用している場合（依存関係に vitest がある、または test スクリプトで vitest を実行している場合など）は、npx vitest run --coverage を実行します。
     3. それ以外で、プロジェクトが Jest を使用している場合（依存関係に jest がある、または test スクリプトで jest を実行している場合など）は、npx jest --coverage を実行します。
     4. それ以外で、別のスクリプトがカバレッジ付きでテストを実行することが明らかな場合（例：coverage、test -- --coverage）は、npm run <script> で実行します。
     5. どれにも該当しない場合は、カバレッジコマンドを特定できなかったことをユーザーに伝え、レポートの後に停止します。
   • 選択したコマンドを実行します。失敗した場合（終了コードが 0 以外、テスト失敗、またはプロジェクトの設定で定められたカバレッジしきい値未達）は、テストを修正します（または、プロダクションコードが正しくテストが誤っている場合に限り、テストを調整します）。同じコマンドを再実行します。成功するまで繰り返します。
   • このステップが成功するまで、検証レポートを完了扱いにしないでください。

8. エッジケースへの対応：

   • ベースブランチと比較してブランチにコミットがない場合は、その旨をユーザーに伝えて停止します。
   • 変更されたファイルにテストファイルとソースファイルの両方が含まれる場合は、ソースファイルをコンテキストとして使用しますが、レポートの対象はテストファイルのみとします。
   • テストファイルが見つからないファイルをインポートしている場合は、その旨を記載しますが、分析は続行します。
   • テストファイルが非常に大きい（500 行超）場合は、該当ファイルの git diff を使い、変更箇所に絞って確認します。