テストレビュー

意図

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

レビュー手順

1. 対象の特定

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

2. TESTING.md の方針を読む

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

3. チェック観点

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

振る舞い vs 実装

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

テストの経済学

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

テストダブルの適切さ

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

テストの品質

• •テストが独立しているか（順序依存がないか）
• •グローバル状態のリセット（__resetForTesting__）が必要な箇所で行われているか
• •非決定的な要素（タイマー、非同期）が制御されているか

構造と可読性

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

cleanup / dispose

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

4. 報告フォーマット

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

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

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

現時点の方針

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

今後の検討事項

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