はじめに
E2E (エンドツーエンド) テストはユーザーに一番近いテストです。
単体テストより、コンポーネントテストより、VR（ビジュアルリグレッション）テストよりユーザーに近いです。
ここで出てくる疑問。
どこまで書けばいいの？
人間の行動をターゲットにするわけですから、色々なパターンが考えられる訳です。
特に、Webを使う人たちというのは僕たちみたいなパソコンオタクじゃないので、ITリテラシーが高くないことも多いです。
どのユーザーのどんな行動まで担保すればいいんでしょうか？
僕曰く
ユーザーの6~7割ぐらいの人が通るメインの動きを担保する（大きな障害を出さないぐらいの気持ちで書くといいなと思います。
なぜこれぐらいの気持ちの方がいいかという話をいかにしていきます。
1. テストケースが増えれば増えるほどリリースが遅くなる
E2Eテストってすごく時間を食います。
小さな変更であったとしても、CIでE2Eテストは動きます。
ビルドやlintはキャッシュから復元してできる限り高速化していくことができます。
これは、結果が変わらないということがわかっているからいいですね。
でも、E2Eテストはユーザーにリリースする前の最終チェックです。スキップはできない。
毎回ヘッドレスブラウザを立ち上げ、一つ一つ実行されていくので時間がかかる。
しかもparallelに動かせないものも多くあります。
テストケースが増えれば増えるほど時間がかかっていきます。
2. 共通化がしづらく、テストケースが増えると保守が難しい
他のテストもそうだったりしますが、特にE2Eの世界では共通化がしづらいです。
めちゃくちゃプログラムを書くのがうまい人でもE2Eを書いてもらうと結構見づらいコードになったりします。
これはしょうがないことです。
現実世界のユーザー行動を共通化しようというのがそもそも間違えているのです。
テストケースを増やしすぎるとメンテナンスがかなりしんどいです。
3. どうせ2~3ヶ月後には変わる
これはアプリケーションの性質に寄ったりしますが、ユーザーに提供する画面の場合、細かいUIや機能レベルで言うと頻繁に変更がかかると思います。
細部まで書いているとその度に変更が必要になります。
まとめ ~ できる限り網羅したいという人へ ~
単体テストやコンポーネントテストを書きましょう。
役割分担があります。
各機能が単体でちゃんと動くことができるのであれば、大きな障害には繋がらないと思います。
ユーザーのためを思うのであれば、ちゃんと単体テストを充実させ、インクリメントを早く提供していった方がいいかと思います。