---

name: test-review description: 既存テストを TESTING.md の方針に照らしてレビューする。テストの品質改善ポイントを特定し、具体的な改善提案を行う。

テストレビュー

意図

テストコードが docs/TESTING.md の方針に沿っているかを体系的にレビューし、改善点を特定する。 テストは仕様を表現するものであり、その品質はライブラリの信頼性に直結する。

レビュー手順

1. 対象の特定

引数でパッケージ名やファイルパスが指定されていればそれを対象にする。 指定がなければ、直近の変更（git diff）に関連するテストファイルを対象にする。

2. TESTING.md の方針を読む

docs/TESTING.md を読み、現在の方針を確認する。方針は更新される可能性がある。

3. チェック観点

以下の観点でレビューし、該当するものだけを報告する。問題がなければ「問題なし」と報告。

振る舞い vs 実装

• テストが実装の内部状態（プライベート変数、内部フラグ）に依存していないか
• 公開 API を通じて観測可能な振る舞いをテストしているか

テストの経済学

• テストが保護しているリスクは何か。そのリスクは投資に見合うか
• カバレッジのためだけに存在するテストはないか
• 高リスク箇所（公開 API、エッジケース、cleanup）は十分にカバーされているか

テストダブルの適切さ

• 過度なモック（内部モジュールのモック）がないか
• モックが外部依存（DOM API、タイマー）の置き換えに限定されているか
• vi.spyOn の復元（mockRestore）が漏れていないか

テストの品質

• テストが独立しているか（順序依存がないか）
• テスト間の状態分離が適切か（スコーピング / mount ライフサイクル優先、__resetForTesting__ は残存グローバル状態にのみ使用）
• 非決定的な要素（タイマー、非同期）が制御されているか

構造と可読性

• AAA パターン（Arrange-Act-Assert）が守られているか
• 命名規則に沿っているか（describe = 対象名、it = 動詞で始まる振る舞い、should 不使用）
• describe のネストが適切か（深すぎないか、機能単位でグループ化されているか）

cleanup / dispose

• リソース確保に対応する解放テストがあるか
• DOM テストで container の後片付けが行われているか

4. 報告フォーマット

レビュー結果は以下の構造で報告する:

対象: packages/<name>/src/__tests__/<file>.test.ts

観点	状態	詳細
振る舞い vs 実装	OK / 要改善	具体的な箇所と提案
...	...	...

改善提案がある場合は、BAD/GOOD のコード例を添えて具体的に示す。

現時点の方針

• 重大な問題（実装依存のテスト、リソースリーク見逃し）は必ず指摘する
• 軽微なスタイル問題は「推奨」として報告し、修正を強制しない
• テストの追加提案は、リスクベースの判断に基づいて行う

今後の検討事項

• パッケージ横断でのテストパターンの一貫性チェック
• テストカバレッジとリスクの相関分析
• 自動チェック可能な項目の CI 統合