テストピラミッドは、下に速く小さいテスト、上に広い範囲を確認するテストを置く考え方です。
| 層 | 確認するもの | 特徴 |
|---|---|---|
| 単体 | 関数や小さなロジック | 速く原因を絞りやすい |
| 結合 | DB、API、複数部品の接続 | 境界の食い違いを見つける |
| E2E | 利用者の操作全体 | 実際の経路を確認できる |
同じことを全部で試さない
割引計算の細かなケースは単体テストへ置き、ログインから購入完了までの主要経路をE2Eで確認します。
E2Eだけが危ない理由
広いテストは安心感がありますが、遅く、失敗原因も広くなります。小さなロジックまでE2Eだけで守ると、修正のたびに確認時間が増えます。
形は固定ではない
UI中心、データ処理中心、外部連携中心では適切な構成が違います。重要なリスクを、最も小さく安定した層で確認します。
ケーススタディ：課題提出機能のテストを配分する
受講生が課題ファイルを提出し、講師が一覧から確認する機能を考えます。仕様には、締切前なら提出できること、許可された拡張子だけ受け付けること、受講生本人と担当講師だけが閲覧できること、提出後に一覧へ反映されることが含まれます。これを一つのE2Eテストだけで確認すると、失敗した時に日時判定、ファイル検証、権限、保存処理、画面更新のどこが原因か分かりません。
まず締切判定と拡張子判定は単体テストへ置きます。締切の一秒前、ちょうど、直後や、大文字の拡張子、拡張子のない名前を高速に試せるからです。次に、提出APIと保存先、認証情報と閲覧権限の組み合わせは結合テストへ置きます。ここでは「保存関数が呼ばれた」だけでなく、保存された提出物を別の利用者が取得できないことまで確認します。最後にE2Eでは、受講生がログインして一件提出し、完了表示と一覧反映を確認する主要経路に絞ります。
良い配分は、各テストが異なる失敗理由を説明できます。単体テストの日時境界が失敗すれば判定式、結合テストだけが失敗すれば部品間の契約、E2Eだけが失敗すれば画面操作や実環境の配線を疑えます。悪い配分は、三つの層で「正常なPDFを一件提出できる」だけを重複確認する構成です。件数は増えても、境界や権限の穴は残り、保守時間だけが増えます。
層を選ぶ判断手順
新しい確認項目を見つけたら、最初に「壊れた時に利用者へ何が起きるか」を書きます。次に、その結果を決める最小の部品を探します。純粋な計算や変換なら単体、データベースや外部APIとの契約なら結合、ブラウザから複数サービスを通る価値提供ならE2Eが第一候補です。ただし、候補の層で本番と同じ危険を観測できないなら一段広げます。たとえばSQLの制約は関数のモックでは確認できないため、結合テストが必要です。
判断時には実行時間、失敗の切り分けやすさ、環境依存、利用者への影響を並べます。「重要だからE2E」ではなく、「どの層なら重要な失敗を最小の範囲で再現できるか」と問い直します。決済完了のように事業上重要な経路でも、金額計算の全組み合わせは単体で守り、代表的な一経路だけをE2Eで通す方が、速さと信頼性を両立できます。
失敗条件と観測方法
テスト群の健全性は本数の比率だけでは判断できません。単体テストが多くても、実装の内部構造を細かく固定し、振る舞いを変えていないリファクタリングで大量に壊れるなら弱い設計です。結合テストが毎回共有データへ依存して順序で結果が変わる、E2Eが待ち時間不足で時々落ちる、失敗ログに入力や対象画面が残らない、といった状態も失敗条件です。
観測では、層ごとの実行時間、失敗頻度、再実行だけで成功した件数、原因特定までの時間を継続して記録します。変更されたコードに近い単体テストが先に失敗し、その説明から修正箇所を絞れるなら下層が機能しています。反対に、本番事故をE2Eでしか再現できず、下層ではすべて成功するなら、事故を決めた契約や境界がどこにも表現されていません。事故の再現テストを最も小さい適切な層へ追加し、必要なら主要経路のE2Eも一本残します。
良い状態は「下が多い」という見た目ではなく、短い確認で多くの誤りを発見し、広いテストが利用者経路の配線を保証している状態です。画面変更のたびにE2Eを直す時間が増えたら、下層へ移せる検証がないかを見直します。一方、単体テストは成功するのに接続障害を繰り返すなら、結合層が薄すぎます。ピラミッドは完成図ではなく、実際の故障記録をもとに配分を調整するための道具です。
よくある誤解：層ごとの本数比ではない
三角形を「ユニット70%、統合20%、E2E10%」という固定比率として使うと、サービスの危険を見落とします。SQL、外部API、ブラウザ互換が重要なら統合やE2Eが増えます。判断するのは本数ではなく、どの失敗をどの境界で最も速く、安定して検出できるかです。テストピラミッドは割合の規則ではなく、遅く壊れやすい検証へ責任を集めないための設計です。
モックが多いユニットテストも、実際の契約と違えば安心材料になりません。提出APIの認可は関数単体だけでなく、ルーティングとDBを含む統合テストで「他人の提出を読めない」を確認します。E2Eでは同じ認可分岐を網羅せず、受講生が提出して講師が確認できる代表経路を守ります。
| 失敗 | 主な層 | 理由 |
|---|---|---|
| 期限判定の境界 | ユニット | 多数の日時を高速に試せる |
| DB制約と保存 | 統合 | 実スキーマが必要 |
| 他人の提出閲覧 | 統合 | 認証・認可・問い合わせを通す |
| 提出ボタンから完了表示 | E2E | ブラウザ全体の接続を守る |
| 外部ストレージ障害 | 統合 | 契約した失敗応答を再現する |
動作確認：失敗理由を一意にする
各テストを意図的に失敗させ、メッセージから壊れた契約が分かるか確認します。E2Eが落ちた時に待機時間を増やす前に、ネットワーク待ち、セレクタ、テストデータ競合、製品不具合を分類します。ユニットで十分な条件をE2Eへ重ねているなら下の層へ移します。
テスト時間、再実行で結果が変わる割合、障害を最初に検出した層、見逃した回帰を記録します。速いテストが多くても重要経路を見逃せば配分を変えます。良い配分は図の形ではなく、失敗が原因に近い層で早く見つかることで確認できます。
まとめ
テストピラミッド入門：どの層で何を確認するかで大切なのは、用語を単独で暗記することではありません。期待、観測、差分、仮説、操作、結果を順に残し、テーマに合う証拠で判断します。小さく確認し、再現できる説明を残すことが、修正と学習の両方を次へつなげます。
参考リソース
保守時に配分を変える
同じ回帰がE2Eで何度も見つかるなら、原因となる関数やAPI契約へ小さいテストを追加します。E2Eを削除するかは別判断で、代表的な利用者経路を守る一本は残せます。反対に、ユニットテストがすべて通るのにDBの大文字小文字、タイムゾーン、外部API形式で障害が出るなら、実物に近い統合テストを増やします。
テストダブルは、置き換えた境界を明記します。決済SDKをモックしても自社コードが正しい引数を渡すことは確認できますが、実サービスの認証、ネットワーク、Webhook順序は保証しません。提供元のテスト環境や契約テストで別に守ります。
並列実行でだけ落ちるテストは、待機時間を増やして隠しません。共有DB、固定メールアドレス、同じポート、時刻への依存を探します。各テストが自分のデータを作り、自分で片付け、順序に依存しない状態を目指します。
