tomevault-io テストレビュー
意図
テストコードが 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 統合
Converted and distributed by TomeVault — claim your Tome and manage your conversions.