エンドツーエンド（E2E）テストピラミッドでは、テストは最上位のラングの1つを占めます。1つのE2Eテストを作成することにより、アプリケーションロジックの結果に自信を持ち、他のシステムとの統合をテストし、アプリケーションの「契約」を作成できます。
残念ながら、私が一緒に働いた同僚の多くはE2Eテストを作成しませんでした。ユニットテストに真っ向から取り組み、TDDの傾向など、さまざまな理由でより良いと考えたことが一因です。E2Eテストは作成が難しいと考えていたため、実行に時間がかかり、計測に問題がありました。
これらの意見を整理して、E2Eテストが提供する長所を見てみましょう。
用語
自動テストのタイプをE2Eテストの下に置きましょう。これらの自動テストは、クライアントの観点からすべてのサービス機能をカバーする必要があります。これを行うには、HTTPリクエストであれ、UIのボタンをクリックする場合であれ、実際のクライアントの相互作用をシミュレートします。
ユニットテストアプローチの方が優れています
私の経験では、ユニットテストの作成にはE2Eテストよりもはるかに時間がかかります。はい、最初はE2Eテストの記述がどのように優れているかを理解する必要がありますが、ユニットテストについても同じことが言えます。
一方、結果として、1つのE2Eテストは、1つのユニットテストよりも多くのコードをカバーしますが、同様のユニットテストスイートと比較して、必要な行数は少なくなる可能性があります。
外部システムがE2Eテストで依存関係になり、テスト対象のサービスとの対話が「ブラックボックス」の原則に従って構築されるため、依存関係を正しくモックする方法を理解するために時間を無駄にする必要はありません。
単一のクラスメソッドのすべての境界条件をチェックする必要はありません。これにより、アプリケーションの内部ロジックをわずかに変更するだけでテストスイート全体をリファクタリングする必要がなくなるため、コードを操作する際の柔軟性が向上します。
, , 100 ( ), .
backend- , API HTTP ( GraphQL) MQ. HTTP, mainstream .
Frontend- , , Web- () . , , , .
E2E , . . .. . , .
E2E
, , .
"" code-coverage. , , , , . exception, , ?
, E2E .
E2E API . , backend, E2E , , frontend .
, , E2E , unit-, .
! , E2E ?