単体テスト を基盤に、結合テスト ・ E2E テスト と上に行くほど少なくする古典的なテスト配分モデル。Mike Cohn が著書『Succeeding with Agile』(2009) で提唱した。
概要
/\
/E2\ ← 少なめ(数十)/ 遅い・高コスト
/----\
/ 結合 \ ← 中くらい(数百)/ 中速・中コスト
/--------\
/ 単体 \ ← 多め(数千)/ 速い・低コスト
/----------\
下に行くほど多く・速く・安く という三角形の配分。長年「テスト戦略の定石」として広く採用されている。
各層の目安
| 層 | 件数 | 速度 | カバー範囲 |
|---|---|---|---|
| E2E | 数十 | 数秒〜 | クリティカルなユーザーシナリオのみ |
| 結合 | 数百 | 数百 ms | モジュール間の連携 |
| 単体 | 数千 | 数 ms | 個別のロジック・分岐・例外 |
なぜピラミッド型か
速度
E2E は 1 件で数秒〜数十秒。これを単体並みに大量実行すると CI が破綻する。 遅いテストほど少なくする のが基本。
コスト
E2E は環境構築・データ準備・実行が高コスト。単体は安い。 コスト効率を最大化 するピラミッド型が合理的。
バグ局在化
単体テストは「どこで壊れたか」がピンポイントで分かる。E2E は「どこかで壊れた」しか分からない。 デバッグ容易性 も下層を厚くする理由。
ピラミッドが向く場面
| 状況 | 向き具合 |
|---|---|
| バックエンド(純粋ロジック中心) | ◎ |
| 計算が多い領域(金融・在庫) | ◎ |
| API 連携が薄い | ◎ |
| 動的型付け言語 | ○ |
ピラミッドの限界
| 弱点 | 内容 |
|---|---|
| モック過剰 | 単体テストを増やすと、結合点のモックが膨らむ |
| 本番との乖離 | モックが本物と振る舞いが違うリスク |
| フロントエンドに合わない | UI は結合・E2E でしか検証できない部分が多い |
これらの弱点を補うために生まれたのが テストトロフィー (結合中心 + 静的解析基盤)。
AI 駆動開発との関係
AI 駆動開発では テストの実行速度がループ速度を決める 。ピラミッドの「単体多め」は、AI ループを高速化する点で理にかなう。
ただし、 単体だけで安心しない こと。AI が生成するコードは結合点で壊れやすいので、結合テストも必ず併走させる。
関連記事
- 開発手法ガイド:テスト技法編 — ピラミッド vs トロフィーの比較
- 開発手法ガイド:TDD 編 — 単体テスト基盤の TDD サイクル
関連用語
参考資料
- Mike Cohn 『Succeeding with Agile』(2009)
- The Forgotten Layer of the Test Automation Pyramid — Mike Cohn