E2E Testing: A Tutorial and Architectural Guide
エンドツーエンド (E2E) テストは、ユーザーのログイン要求など、アプリケーションの最も重要なフローを検証するために役立ちます。 フロントエンドの開発では、E2E テストは、正しい UI が提示されているかどうかを検証するのに役立ちます。 バックエンドの開発では、E2E テストは、バックエンド サービスの重要なフローが期待される出力を返すかどうかを検証するのに役立ちます。
この投稿では、E2E テストについて紹介し、実行可能なヒントを提供します。 また、より簡単に E2E テストを作成するために、再利用可能なテストの書き方についても説明します。 ご存知のように、E2E テストは、記述、実行、および保守に多くの労力を要するため、開発者にとって大きなフラストレーションとなります。
最初に、ソフトウェア テスト ピラミッドの中で E2E テストがどこに位置しているかを見てみましょう。
テストピラミッドにおける E2E テストの位置
テストピラミッドを見ると、コードの品質を保証するために、4 つの主要なテストタイプがあります：
- E2E テストはアプリケーションの価値の高い経路を検証するのに役立ちます。 言い換えれば、それらはしばしばアプリケーションのフローを表すので、ユーザーストーリーを検証するのに役立ちます。 統合テストは、あなたのコードが他の機能と密接に動作するかどうかを教えてくれます。
- ユニットテストは、機能のビジネスロジックを検証するのに役立ちます。 ユニットテストはテストの最も基本的な形式であり、ビジネスロジックが正しいことを確認します。
- 最後に、静的解析または静的テストを忘れることはできません。
このピラミッドによると、ほとんどのテストはユニットテストであるべきで、統合テストは少なく、E2Eテストはさらに少なくなっています。 しかし、アプリケーションのフローを検証することはまだ重要です。 E2Eテストはメンテナンスが大変で、多くの労力を必要とします。 そのため、E2Eテストでは、最も重要なフローのみを検証するようにします。
Different E2E Testing Strategies
異なる戦略が存在することをお伝えしましょう。 私たちは、水平 E2E テストと垂直 E2E テストのいずれかを選択できます。 両方の戦略は、異なるシナリオをテストすることができるため、探索する価値があります。
戦略その 1: 垂直エンドツーエンド テスト
この戦略は、テスト ピラミッドのすべての層をテストすることに焦点を当てます。 これには、ユニット テスト、統合テスト、および UI テストが含まれます。 あなたの目標は、単体テストを使用して粒度の細かいレベルでコンポーネントをテストし、統合テストを使用して他のコンポーネントと相互作用するときにコンポーネントがどのように動作するかをテストし、最後に、ユーザーが UI を介して相互作用するときにコンポーネントの動作を検証することです。
最も一般的には、継続的インテグレーション パイプラインを使用して、すべてのコード コミットまたはプル リクエストに対してこれらのテストを自動化します。
戦略その 2: 水平エンドツーエンド テスト
水平 E2E テストでは、完全なユーザー フローを検証することに焦点を合わせます。 ここにウェブショップのサンプル フローがあります。
- 製品ページを開く
- 製品サイズを選択する
- 製品を買い物かごに入れる
- チェックアウトに進む
- 住所と支払情報を入力する
- 支払いを完了する
- 買い物確認画面を表示する
ここで、ユーザーフローの各処理を確認したいのですが、どうすればいいですか。 多くの場合、このタイプのテストでは、異なるアプリケーション間の相互作用を検証し、それらのアプリケーションの状態変化を確認します。
これらのタイプのテストは書くのにお金がかかることに注意してください。 ユーザーフローを定義し、これらのテストを書くには、かなりの時間がかかります。
しかし、これらの重要なユーザーフローをさまざまな条件下でテストすることを確認します。 この戦略により、ユーザー フローの堅牢性の全体像を把握することができます。 これらの条件には、
- 複雑なタイミング シナリオが含まれます。 たとえば、コンサートのチケットは 15 分間しか利用できません。
- 異なるデータの入力またはデータの欠落。
- フローの分断。 ユーザーがチェックアウトページを離れて別の商品ページを表示することを決定した場合。
次に、いつ E2E テストを書くかを学びましょう。
When to Write E2E Tests
あなたは、E2E テストが継続的統合パイプラインで実行する高価なテストであることを知らないかもしれません。 それらはしばしば、実稼働データを模倣するデータベースの作成など、多くの準備を必要とします。 さらに、それらは時々、あなたのアプリケーションの時間のかかるフローを表します。
E2E テストを使用して、アプリケーションの最も重要なフローを検証してください。
- Login and logout
- Register a new user
- Add item to cart
- Change your password
- Any other important flows related to your service
しかし、ユニットテストや統合テストで、あなたが書いたビジネスロジックも忘れず検証するようにしましょう。 ユニット テストと統合テストの両方を組み合わせることで、コードの品質について十分な自信を持つことができるはずです。
Tips for Writing E2E Tests
Focus on Writing Reusable Tests
最初で最も重要なヒントは、小さくて独立した、再利用可能なテストとコンポーネントを書くということです。 これにより、複数の小さなコンポーネントをひも付け、完全なエンド ツー エンドのユーザー フローをより簡単に作成することができます。 E2E テストで使用するためだけに多くのカスタム コンポーネントを書くのではなく、再利用可能なコンポーネントを書くことに集中します。
小さく、独立したコンポーネントを書くことは、コードの再利用に役立ち、エラーのトラブルシューティング時間を短縮します。 また、機能やユーザーフローが変わったときに、小さなコンポーネントを更新するのも簡単です。
Always Consider the Reason for Writing an E2E Test
E2E テストで特定のフローをカバーしたいとき、それをカバーする価値があるかどうかを検討します。 E2E テストでテストするのは、価値の高いユーザー フローだけにしてください。 たとえば、ユーザーが間違った電子メール アドレスを入力すると、エラー メッセージが表示されるかどうかをテストするべきではありません。 これは、あまりにも単純なユースケースであり、E2Eテストに適していません。
その一方で、ログインに成功した後、ログインページが正しいアプリケーションページにリダイレクトされるかどうかをテストする価値があります。 これは、ユーザーがアプリケーションを使用できるようにするための貴重なフローです。
E2E Tests Shouldn’t Depend on Implementation Details
あるフローの実装詳細を変更するたびに、E2E テストを更新する必要はないでしょう。 したがって、実装の詳細を抽象化できるようなコンポーネントを書きたいものです。 実装の詳細がコンポーネントに隠されていると、E2Eテストのメンテナンスがずっと楽になり、書くのがより楽しくなります。
Pitfalls of E2E Testing
E2E テストに関連する共通の落とし穴のリストは次のとおりです：
- E2E テストは一度にできるだけ多くのテストをしようとすべきではありません。 多くの場合、開発者はユーザー フローのあらゆる側面を検証する巨大な E2E テストを書きます。 物事をシンプルに保ち、ユーザーフローの最も重要な側面を検証してください。 例えば、ログインフローでは、ユーザーがアプリケーションページにリダイレクトされたかどうかだけを検証すればいいのです。
- E2E テストが失敗するたびに、失敗の正確な原因を見つけるのは難しいかもしれません。 しかし、ビジネス ロジックをユニット テストと統合テストでカバーすることにより、必要なデバッグの労力を減らすことができます。 いくつかのツールは、失敗したテスト ステップのスクリーンショットやコンソール ログなど、優れた根本原因の分析を提供し、トラブルシューティングの時間を短縮します。
- E2E テストは、継続的インテグレーション (CI) パイプラインでかなりの時間を必要とします。 CI パイプラインをブロックする可能性があり、開発全体の速度が低下します。 これは、テストを実行するためのいくつかのより多くのパイプラインを持つために、CI パイプラインに投資する必要があるかもしれないことを意味します。
- E2E テストは、継続的な努力です。 新しい機能が追加されたり、古い機能が変更されたりするたびに、E2E テストを更新する必要がある可能性があります。 しかし、実装の詳細を抽象化する再利用可能なコンポーネントを書くことで、この労力を軽減することができます。 さらに、一部のツールでは、コードが変更されたときにテストを適応させるために AI を使用して、テストのメンテナンスを軽減します。
さて、システムテストと E2E テストの違いについて簡単に見てみましょう。 システム テストは、機能的要件と非機能的要件の両方を検証することに重点を置いています。 多くの場合、アプリケーションをブラックボックスとして扱う外部チームによって完成されます。 言い換えれば、彼らは、アプリケーションが満たすべき要件以外のアプリケーションの機能については何も知らないのです。 しかし、システムテストはE2Eテストよりもはるかに多くのことを検証する。 例えば、システムテストでは、スケーラビリティやパフォーマンス、信頼性などを測定する。
最後に、この記事の学びをまとめましょう。
E2E
エンドツーエンドテストは、価値の高いユーザーフローまたはユーザーストーリーを検証するのに役立つので、かなり強力です。
しかしながら、E2E テストを書き、維持するには、かなりの時間と労力を必要とします。 実装の詳細を抽象化する、小さくて再利用可能なコンポーネントを書くことによって、この労力を削減することが可能です。 また、一部のツールは、AI または複数の属性を使用して各要素を識別することにより、より弾力性のあるテストの作成を支援します。 そのため、価値の高いユーザーフローで実装の詳細が変更されるたびにE2Eテストを更新する必要はありません。 さらに、再利用可能なコンポーネントを使用すると、それらのコンポーネントを連結して E2E テスト フローを簡単に作成できます。
E2E テストは、アプリケーションの最も重要なフローをカバーする必要があります。 ユーザーと顧客がアプリケーションから価値を得るためにたどるフローをテストします。 ログインできない、もしくはカートに商品を追加できない場合、彼らは (可能であれば) 去るか、もしくはあなたのアプリケーションを使わざるを得ないのであればサポートに電話するでしょう。 たとえば、ログインとログアウトのフローをカバーしたいが、間違った電子メールアドレスを入力した後のエラーメッセージを検証することにはあまり興味がない、といった場合です。 また、書いて維持するために多くの時間や労力を必要とすべきではありません。 E2Eテストをシンプルに保ち、再利用可能なコンポーネントに焦点を当てれば、素晴らしい結果が得られるでしょう！
この投稿はMichiel Mulders氏によって書かれました。 Michiel は、技術的なコンテンツを書くのが好きな、情熱的なブロックチェーン開発者です。 それ以外にも、マーケティング、UX心理学、起業家精神について学ぶことが大好きです。 彼が書いていないときは、おそらくベルギービールを楽しんでいることでしょう！
。