Test suite design

Test Suite Design

「何を」「どの層で」テストするかを決めるためのスキル。1つのテストを書く手順（Red-Green-Refactor）は test-driven-development が担当するため、このスキルはテストスイート全体の設計・配分・重複排除に専念する。

使うタイミング

• 新機能・新プロジェクトのテスト戦略を決めるとき
• 既存のテストカバレッジをレビューし、過不足を指摘するとき
• テストスイートの実行時間が肥大化し、削るべき重複を見つけるとき
• 「このロジックはユニットテストとE2E、どちらでカバーすべきか」を判断するとき

手順

ステップ1：テストピラミッドの構成比率を確認する

1. 下層：高速なユニットテストを大量に配置する。1関数・1クラスの純粋なロジックを対象にする。
2. 中層：統合テストを適量配置する。実DBのローカルインスタンスを使い、外部APIはテストダブル（Wiremock等）で模擬する。
3. 上層：E2E/UIテストは最小限に絞る。遅く壊れやすいため、ユーザーが実際に取る主要な導線（クリティカルパス）のみをカバーする。
4. 「逆ピラミッド（アイスクリームコーン型：E2Eに偏重）」になっていないか定期的に点検する。E2Eの数がユニットテストの数を上回っていたら要警戒。

ステップ2：どの層でテストすべきかを判断する

新しいロジックを見たら、以下の順で「最も低い層でテストできないか」を検討する。

判断基準	テスト層
純粋なロジック（入力→出力が決定的、外部依存なし）	ユニットテスト
DB・外部APIとの連携、複数モジュールをまたぐ振る舞い	統合テスト
ユーザーが画面越しに操作する主要フロー全体の疎通確認	E2E（最小限）
UIの見た目・スタイルのみの確認	テスト不要か、スナップショット程度に留める

原則：同じ振る舞いを上位層と下位層で二重に検証しない。上位層は「結線されているか」の確認に留め、ロジックの分岐網羅は下位層に任せる。

ステップ3：テスト重複を削減する

テストスイートの実行時間が肥大化してきたときの手順：

1. 上位レベル（E2E・統合）のテストがバグを検出したのに、対応する下位レベル（ユニット）のテストが存在しない場合、まず下位レベルのテストを追加する。
2. 下位レベルでカバーできたことを確認してから、上位レベルの重複部分（同じ分岐・同じエッジケースを繰り返し検証しているテスト）を削減する。
3. 削除の前に「このE2Eテストは配線・結合部分の確認として意味があるか」を確認する。意味がなければ削除、意味があれば1〜2ケースに絞る。

ステップ4：テストの粒度を決める

• 1テスト＝1つの振る舞い（1アサーション相当）を原則にする。複数の関心事を1テストに詰め込まない。
• テスト名は「状況＋操作＋期待結果」の形式にする（例：空のカートに商品を追加すると合計金額が更新される）。テストが落ちたときに名前だけで契約違反箇所がわかることを目指す。
• エッジケース（空入力、境界値、異常系、並行実行）をテストリストに明示的に含める。「正常系だけ書いて満足」を避ける。
• 実装の内部詳細（プライベート変数の値、呼び出し回数の細部）に依存しすぎるテストは、リファクタリング耐性を下げるため避ける。公開された振る舞いを検証する。

ステップ5：カバレッジレビュー時のチェック

既存プロジェクトのテストをレビューするときの観点：

• クリティカルパス（決済、認証、データ削除など）にユニット＋統合の両方がある
• エッジケース・異常系がテストリストに含まれているか
• 同じ分岐を3層すべてで重複検証していないか
• E2Eテストの数が全体の1〜2割を超えていないか（プロジェクト規模により変動するが、E2E偏重の兆候として使う）
• テスト名から「何を保証しているか」が読み取れるか

チェックリスト（新機能着手時）

• このロジックはユニットテストで検証できる部分と、結合が必要な部分に分解したか
• E2Eを追加する前に、同じ振る舞いをより低い層で検証できないか検討したか
• エッジケースをテストリストに書き出したか
• 意味の薄いテスト（実装詳細への依存が強いテスト）を増やしていないか

アンチパターン集

アンチパターン	現実
すべての振る舞いをE2Eで確認しようとする	遅く壊れやすいテストが増え、CI時間が肥大化し、フレーキー（不安定）なテストの温床になる
ユニットテストと統合テストで同じ分岐を何度も検証する	実行時間が無駄に伸びるだけで、バグ検出力は上がらない。層ごとに役割を分ける
「カバレッジ率100%」を目標にする	意味の薄いテスト（getter/setterの単純テスト等）が量産され、本当に重要なエッジケースが漏れる。カバレッジ率ではなく「クリティカルパスが守られているか」を見る
テスト名がtest1, testCase2のような機械的な名前	テストが落ちたときに何を保証していたかがわからず、調査コストが増える
実装の内部状態（プライベート変数）を直接検証する	リファクタリングのたびにテストが壊れ、テストが「変更を安全にする」という本来の役割を果たさなくなる

出典

• Martin Fowler: Practical Test Pyramid — テストピラミッドの構成比率、重複削減の考え方を要約。
• Kent Beck / 和田卓人の解説（t-wadaのブログ「自動テストとテスト駆動開発、その全体像」）— テスト名の構造化、エッジケースの明示に関する知見を要約。