テストピラミッド（Test Pyramid）

テストピラミッドは、自動テストを各レベルにどう配分するかの指針です。幅の広い土台はユニットテストで、高速、安価、かつ精密です。中段は結合テストまたはサービステストです。細い頂点は UI を通した E2E テストで、最も現実に近い安心感を与えてくれますが、最も遅く壊れやすいテストです。Mike Cohn によって広められたこの考え方は、各チェックを、その問題を検出できる最も低いレベルまで押し下げるというものです。

例

「100 ドルを超える注文は送料無料」というルールを考えます。

• ユニット: 送料計算関数を $99.99、$100.00、$100.01 でテストします。それぞれ数ミリ秒で、ブラウザーは不要です。
• 結合/API: 120 ドルのカートで POST /orders を呼び出し、レスポンスに shipping: 0 が含まれることをアサーションします。これでルールがサービスに組み込まれていることを証明できます。
• E2E: 条件を満たすカートで決済を完了し、確認ページに「送料無料」と表示されることを確認する UI テストを 1 つ。

境界値のために UI テストを 10 個作る必要はありません。計算の正しさはユニットテストがすでに証明しています。

なぜ形が重要なのか

上位レベルのテストほど多くのコンポーネントに触れるため、失敗してもバグの場所についてわかることは少なくなります。また、ブラウザー、環境、テストデータが必要になるため、遅くなり、フレーキーになりやすくなります。大半が UI テストのスイート（「アイスクリームコーン」アンチパターン）は何時間もかかり、変更とは無関係な理由で失敗し、やがて無視されるようになります。

批判と代替モデル

ピラミッドは経験則であり、割り当てノルマではありません。「テスティングトロフィー」のような代替モデルは、モックを多用したユニットテストは本物のシステムが壊れていても合格しうると主張し、結合テストにより重きを置きます。どちらのモデルも重要な点では一致しています。遅くて範囲の広い UI テストは少数に抑えて重要なユーザージャーニーに集中させ、安心感の大部分はより高速なレイヤーから得る、ということです。バランスは固定の比率ではなく、実際にバグがどこから生まれているかに基づいて決めましょう。