調べようと思ったきっかけ
- フロントエンドで書くテストがjestでの単体テストが多く、E2Eテストについてあまり理解していなかった
- あわよくばプロジェクトにも導入してみたい...
ということで、今のプロジェクトに導入できそうか？ の観点も含めて調べていきたいと思います！(ちょこちょこ、筆者の気持ちが入りますw)
今のプロジェクトはAPIサーバーとしてRais、フロントエンドにReactを採用したSPA環境となっています。
E2Eテストってナニ？😕
E2Eテストは、End to Endの名前の通り、ユーザーの操作から始まり、サーバーへのリクエスト、データベースへのアクセス、そして最終的にユーザーに表示される結果までが意図した挙動になっているかをテストできます。
つまり、最もユーザーに近い体験でできるテストです。
[筆者の気持ちコーナー] ぜひ、導入してみたい！🤩
E2Eテストのメリット、デメリット👍👎
メリット
- テストできる範囲が広い
- 影響範囲が複数のコンポーネントにまたがるため
デメリット
- コストが高い
- テスト用にサーバーやDB、外部サービスとの連携などの用意が必要
- 不安定
- テストデータが違ってたり、外部APIを使用していたりすると、冪等性が保証されづらい
[筆者の気持ちコーナー] おっと、意外とコストかかりそうだな😕
目的別での分類
ひとくちにE2Eテストと言っても、いろいろあるっぽかったです。
厳密にはE2Eと呼ぶのか賛否あるっぽかったですが、総合してE2Eテストと呼ばれてるぽかったです。
- ブラウザ固有の機能連携を含むUIテスト
- 目的
- ブラウザ固有の機能、インタラクションをテストしたい(見た目より)
- 例
- メディアクエリによる表示要素の切り替え
- 画面サイズから算出するロジック
- 目的
- DBやサブシステム連携を含むE2Eテスト
- 目的
- 本物に近い環境でテストしたい(機能より)
- 例
- Redisなどの外部ストレージでのセッション管理
- S3などを利用したファイルアップロード
- 目的
[筆者の気持ちコーナー] UIが重要なサービスじゃないから、やるなら「DBやサブシステム連携を含むE2Eテスト」かな🤔
現在(2023)におけるフロントエンドのテストの考え方
背景
- React、VueなどのモダンJavaScriptを使ったSPAの流れでフロントエンドがより複雑になった
- 状態管理やキャッシュ管理、etc... (viewを表示する以外の仕事が増えた)
- コンポーネントを組み合わせた開発が主流になった
TestingTrophyモデルの誕生
- コンポーネントを組み合わせて使っていくのが主流 → 結合テストが多い方が良いんじゃね？
- 結合テストを増やして、ユースケースのカバレッジを上げていこう♪
[筆者の気持ちコーナー] あれ、プロジェクトに導入するにはオーバーかな？😓
E2Eでよく使われるライブラリ
- Cypress
- Selenium
- PlayWright
なんか、プロジェクトにE2Eを導入する可能性が薄くなってきたので、モチベが上がらなくなってきましたが、
npm trendsで直近1年間の結果を調べると、以下の結果になりました。
Cypressが一番人気ですが、PlayWrightも人気そうですね
結論
以下の理由から、今のプロジェクトには導入しなさそう。。。
- TestingTrophyモデルの考えをもとに、一番重視する結合テストを優先するべき
- プロジェクトの特性上、そこまでUIが重要ではなく、DBなどの外部との連携もシンプルなので、結合テストを差し置いてE2を取り入れる理由がない
まずは、結合テストからコツコツ頑張ります！！！！！ 
参考資料