答え。

自動テストはユニット（unit）、統合（integration）、エンドツーエンド（end-to-end、E2E）に分類され、システムの異なるレベルでの検証を包括的にカバーします。

背景: この分類は、アプリケーションを部分的にだけでなく全体としてもテストする必要があるために登場しました。したがって、テスト層が区別されます：

• 特定の機能（unit）
• 部品間の相互作用（integration）
• ユーザーのために動作する全システム（E2E）

問題: バグはしばしば単純なメソッドのロジックだけでなく、コンポーネント間の接続部分や、外部サービスと一緒にシステム全体を「実際」に起動する際にも発生します。すべてを一緒にしてしまうと、バグのローカライズが難しく、どこで発生しているのかがわかりにくくなります。

解決策:

• ユニットテストは、通常は関数や単純なクラスのレベルで、孤立したコードを検証します。高度な場合にはモックやスタブを使用します。
• 統合テストは、複数のコンポーネント（例えば、モジュールとDB）を結びつけ、それらがどのように連携するかを確認します。
• エンドツーエンドテスト（E2E）は、ユーザーのシナリオを模倣し、「ボタンから結果まで」の全経路をテストします。

テストのタイプを区別することは、生存にとって必要不可欠です：

1. サポートコストを最小化（E2Eテストは高価）
2. 迅速なフィードバックを保持（ユニットテストは瞬時）
3. 偽陽性の数を減少させる。

重要な特徴:

• テストの適切な配分は、堅牢な「ピラミッド」アプローチ（テストピラミッド）を構築するのに役立ちます。
• テストスタイルの混合は、バグのローカライズの問題を引き起こします。
• 各層の目的を明確に理解することで、最大の効率を得られます。

トリッキーな質問。

統合テストを単に「大きな」ユニットテストと見なすことはできますか？

いいえ、統合テストは複数のコンポーネントの連携をテストし、単一の機能だけではありません。それに、常にモックを使用できるわけではなく、実際のサービス同士が相互に作用しています。

すべてのテストはエンドツーエンド（E2E）であるべきですか？

いいえ、それは高価で複雑なアプローチです。E2Eは重要なユーザーシナリオにのみ必要であり、ほとんどのロジックは他のテストでカバーされます。

ユニットテストは常に迅速ですか？

必ずしもそうではありません。コードを孤立させることができない場合や、メソッドが複雑な外部リソースに依存する場合があります。そのような場合、テストはユニットでなくなります。

よくあるミスとアンチパターン

• すべてのテストがエンドツーエンドで書かれ、フィードバックが非常に遅くなります。
• 層の混同：ユニットテストがDBやAPIを使い始め、E2Eがモックに基づいて構築されます。
• ユニットテストだけが残され、コンポーネント間の接続での問題のあるバグが見逃されます。

実生活の例

ネガティブケース

会社は主な機能をE2Eテストでカバーしました — 各修正は夜間にチェックされ、テストは不安定に落ち、バグは遅れて発見されました。

利点:

• 実際のユーザーシナリオがカバーされています。

欠点:

• 遅いフィードバック。
• 故障の原因の調査に時間がかかる。
• 多くの偽陽性。

ポジティブケース

チームはテストピラミッドを構築しました：下 — ユニットテスト、中間 — 統合テスト、上 — 最も重要なE2Eのみ。

利点:

• コードがどこで壊れたかがすぐにわかります。
• テストのサポートが簡単です。

欠点:

• 層の分割に良い規律が必要です。