前回の ポスト である フロントエンド は何を テスト するべきですか？ では、フロントエンド での ユニットテスト と統合テスト について集中的に取り上げた。今回の ポスト では フロントエンド のもう一つの テストタイプ である E2E テスト について学び、E2E テストツール である Cypress を活用して、筆者が実際に進行中の サイドプロジェクト で E2E テスト を作成してみることで、これを通じて E2E テスト作成方法まで取り上げようとする。。
1. なぜ E2E テスト をしなければならないのか？
E2E（End-to-End）テスト は アプリケーション の流れを最初から最後まで検証するもので、前述の ユニットテスト と統合テスト とは別の意味を持つ。 ユニットテスト と統合テスト は、開発者の観点から開発した モジュール が正常に動作していることを検証しますが、E2E テスト は ユーザー の観点から アプリケーション の動作を検証するためです。 そのため、E2E テスト は主に実際の ユーザー が アプリケーション を使用する ブラウザ環境で行われ、ほとんどの E2E テストツール が テストプロセス を スナップショット や動画で見る機能を提供しています。
E2E テスト が実際の ユーザー環境で進行できるという点は長所ですが、同時に短所でもあります。 このため、E2E テスト は重くなり、アプリケーション全体を実際の環境に上げる必要があるため、オーバーヘッド が非常に大きい。 したがって、E2E テスト は ユーザー の主な使用フロー を検証するか、モジュール間の統合検証にのみ使用する必要があり、各モジュール が正常に動作するかどうかを ユニットテスト または統合テスト で検証する必要があります。
しかし、フロントエンド では UI と ロジック が結合されており、多くの テスト が E2E テスト で作成される逆ピラミッドテスト（アイスクリームコーン）アンチパターン が頻繁に発生する。 E2E テスト は実行時間が長く管理が難しいため、@testing-library などの ライブラリ を使用して コンポーネント単位の独立した テスト を作成する必要があります。独立した テスト を作成する方法は、フロントエンド は何を テスト する必要がありますか？記事を参考にしましょう
欠点があるが、開発者が作成した モジュール が統合され、アプリケーションレベル で ユーザー が使用するときに正常に動作することを保証できる テスト は E2E テスト だけです。 したがって、E2E テスト も非常に重要であると言える。
私の考えでは、E2E テスト が非常に便利な2 つの ケース があります。 1 つ目は、ビジネス の観点から ユーザー の主な パス が正常に機能していることを確認することです。 2 つ目は ATDD（Acceptance Test Driven Development）を適用する場合です。一部の モジュール が正常に動作していなくても、ユーザー の主な経路が正常に動作している場合、ビジネス の観点から クリティカル な問題ではない可能性があります。 しかし、主な経路が正常に動作しない場合、これは非常に大きな問題になる可能性があります。 これらの テスト を書くとき、E2E テスト は非常に適しています。
また、私は買収テスト主導開発（ATDD）が ユーザーストーリー単位で繰り返し周期を持って アジャイル に開発する チーム に非常に適した方法だと考えています。 する。 ATDD は、利害関係者間で開発完成物についての議論をより深く導き、開発完了を明確に定義することができ、非常に魅力的であり得る。実際、私が今回の サイドプロジェクト に cypress ベース の E2E テスト を導入した理由も、次の プロジェクト で ATDD を適用してみるためだ。
2. なぜ Cypress であるか。
Cypress は人気のある E2E テストツール です。 Cypress はしばしば Selenium と比較されますが、これら2 つの主な違いは アーキテクチャ にあります。 Selenium は ブラウザ の外部で実行され、ネットワーク を介して リモート で コマンド を実行しますが、Cypress は アプリケーション などの実行ループ で コマンド を実行します。 したがって、Selenium は特定の プログラミング言語に拘束されることなく書くことができますが、遅く、言語に適した モジュール を追加設定する必要があります。一方、Cypress は JavaScript でのみ作成できますが、より高速で統合的です。 したがって、JavaScript ベース の フレームワーク で アプリケーション を開発している場合は、Cypress を使用して E2E テスト をすばやく適用できます。
2.1 ページオブジェクトモデル対アプリケーション作業モデル
前述のように、E2E テスト は メンテナンス が他の テスト よりも困難であるため、これを簡単にするための技術を適用することが多い。 Selenium では、このために「ページオブジェクトモデル」 という手法をよく使用しています。 しかし、Cypress コミュニティ では「アプリケーション作業モデル」 の使用を推奨している。 この2 つの違いは何ですか？
ページオブジェクトモデル
ページオブジェクトモデル は ページ の オブジェクト を作成し、その ページ の要素と アクション を対応する オブジェクト に定義します。 つまり、ページ の上にその ページ に関連する タスク を カプセル化する抽象化された階層を構築するのだ。 このように、変動が発生したときにより柔軟に対応することができます。 たとえば、要素の ID が変更されたときに一般的にすべての テスト を修正しなければならないが、ページオブジェクトモデル では ページクラス で要素を見つけて修正すればよいからである。
cypress では、次のように ページオブジェクトモデル を作成できます
