開発を学んでいると、誰もが一度は壁にぶつかります。
「ユニットテスト、結合テスト、UIテスト……いったい何が違うの？」
先に結論をお伝えします。
3つのテストは検証範囲が異なります。ユニットテストは1つの関数、結合テストはモジュール間の接続、UIテストはユーザー画面全体を確認します。
この3つをどの割合で組み合わせるかを示す指針が、テストピラミッドです。今日は私の経験も交えながら、わかりやすく説明します。
まずは要点をまとめます
忙しい方のために、先にまとめます。
- ユニットテスト: 1つの関数・クラスだけを検証。速く、多く書く。
- 結合テスト: 複数のモジュールを接続したとき正しく動くか検証。数は中程度。
- UIテスト: 実際の画面を操作するように全体の流れを検証。遅く、少なく。
- テストピラミッド: 下のユニットテストを広く、上のUIテストを狭く積む原則。
この4行だけ覚えても、半分は理解できたことになります。では、1つずつ見ていきましょう。
ユニットテスト・結合テスト・UIテスト、何が違う？
最も混乱しやすい部分なので、たとえ話から始めます。
車を作ると考えてみてください。
ユニットテストは、1本のねじやボルトが規格に合っているかを見る検査です。とても小さな単位ですね。
結合テストは、エンジンと変速機を接続したとき、うまくかみ合って動くかを見る検査です。
UIテストは、完成した車に乗り込み、エンジンをかけて運転する検査です。
表で比較すると、次のように整理できます。
| 区分 | 検証範囲 | 速度 | 作成数 |
|---|---|---|---|
| ユニットテスト | 1つの関数・クラス | 非常に速い（ms） | 多い |
| 結合テスト | モジュール間の連携 | 普通（秒単位） | 中程度 |
| UIテスト | ユーザーフロー全体 | 遅い（数十秒） | 少ない |
本質的な違いは、どれだけ広く見るかです。
範囲が広いほど実際の利用環境に近づきますが、その分遅くなり、管理も難しくなります。
ユニットテストはこんな感じです
言葉だけではイメージしにくいので、短い例を見てみましょう。
以下は、2つの数値を足す関数だけを取り出して検証するユニットテストです。
// 足し算関数だけを検証するユニットテスト
func add(_ a: Int, _ b: Int) -> Int {
return a + b
}
@Test func 足し算_2_足す_3は_5() {
#expect(add(2, 3) == 5)
}外部データベースも画面も必要ありません。関数1つだけを切り出して確認します。
そのため、実行は一瞬で終わります。数百個を実行しても数秒で済みます。
私はこの速さが気に入って、ユニットテストを最も多く使います。コードを直してすぐ確認できるからです。
テストピラミッドとは？
ここから今日の主役、テストピラミッドです。
2009年にマイク・コーン（Mike Cohn）が著書『Succeeding with Agile』で提唱した概念です。テストを三角形に積み上げる指針です。
- 最下層（広く）: ユニットテスト — 最も多く
- 中央: 結合テスト — 適度に
- 最上層（狭く）: UIテスト — 最小限
なぜこの形なのでしょうか？
下に行くほど速く、安価になるからです。ユニットテストなら数千個実行しても負担になりません。
一方、UIテストは遅く、画面が少し変わっただけでも簡単に壊れます。保守コストも高くなります。
安くて速いテストを多く、高くて遅いテストを少なく。これがテストピラミッドのすべてです。
ピラミッドを逆さに積むと「アイスクリームコーン」アンチパターンと呼ばれます。UIテストばかり多く、ユニットテストがない状態です。遅く壊れやすいテストに振り回されやすくなります。
では、割合はどう決めればよいのでしょうか？
多くの方が気になるところです。
よく引用される目安は、**ユニット70%：結合20%：UI 10%**程度です。
ただし、絶対的なルールではありません。プロジェクトの性質に応じて柔軟に調整してください。
たとえばバックエンドAPIサーバーなら、結合テストの割合を少し高めるのが実用的です。Googleのような組織も、正確な数字より「ピラミッドの形を維持する」方向性を重視しています。
私自身の経験から、もう1つアドバイスします。
数字にこだわりすぎないでください。大切なのは、「遅くて壊れやすいテストに依存しすぎていないか」を確認する習慣です。
よくある質問（Q&A）
Q. E2EテストとUIテストは同じですか？
ほぼ同じ意味で使われますが、厳密には異なります。E2E（End-to-End）はユーザー視点で全体の流れを検証すること、UIテストはその中でも画面操作に焦点を当てることです。実務では混同されることも多いです。
Q. 結合テストをしっかり書けば、ユニットテストは不要ですか？
おすすめしません。結合テストでは、どこで問題が起きたのか特定しにくいからです。原因を素早く絞り込むにはユニットテストが必要です。
Q. テストは最初からすべて書くべきですか？
いいえ。まずは重要なロジックのユニットテストから始めることをおすすめします。最初から完璧なピラミッドを作ろうとして疲れ果てる人を、私は何度も見てきました。
この3つの違いは文章だけでは漠然としていても、実際にコードを書けば体感できます。
今日学んだことを生かして、まずは小さな関数1つにユニットテストを付けてみてください。その感覚が身につけば、残りは自然についてきます。応援しています！