E2Eテストとは何か？ CI/CDで失敗しないための基礎、仕組み・種類・自動化を徹底解説

E2Eテストとは何か？「通ったのに本番で壊れる」に備える

　開発チームがテストを自動化し、画面には毎回「成功」の表示が並ぶ。ところが後から調べると、本来走るはずだったE2Eテストそのものが一度も起動していなかった。こうした事態は、自動化を進めた開発現場ほど起こり得る。

　たとえば、開発基盤として広く使われるGitHub Actionsには、自動処理が発生させたイベントでは別のワークフローを起動しない仕様がある。公式ドキュメントによると、リポジトリ用の認証トークン「GITHUB_TOKEN」を使った操作で発生したイベントは、一部の例外を除き新しいワークフローを作らない。処理が無限に連鎖するのを防ぐための仕組みだという。したがって設定を誤れば、後続のテストが静かに動かない状態が生まれ得るわけだ。

　では、そもそもE2Eテストとは何か。E2EはEnd-to-End（端から端まで）の略で、実際のユーザー操作に近い形で、統合されたシステムを最初から最後まで確認するテストを指す。米IBMは、アプリケーションのワークフロー全体を始めから終わりまで検証する手法だと説明している。

　ECサイトで考えると分かりやすい。ログインし、商品を探してカートに入れ、購入手続きを経て決済が完了する。E2Eテストは、この一連の流れを1本のシナリオとして通しで動かし、途中で画面が止まったり金額がずれたりしないかを確かめる。どこからどこまでを1本にするかは、ユーザーが目的を達成するまでを単位に考えると整理しやすい。


　なお、単体テスト、結合テスト、システムテスト、E2Eテストの呼び方や範囲は、組織や開発プロセスによって多少異なる。本稿では、実際のユーザー操作に近い形で、統合されたシステムを端から端まで検証するテストをE2Eとする。

単体・結合テストと何が違う？ テストの全体像を整理

　E2Eの位置付けをつかむには、ほかのテストと並べてみるとよい。単体テストは、関数やクラスといったプログラムの「部品」が1つずつ正しく動くかを確かめる。次の結合テストは、部品同士や、アプリとデータベースなどの「つながり」を確認するものだ。

　これに対し、E2Eテストが見るのは一連の利用体験が成立するかどうか。個々の部品が正しくても、組み合わせた結果、画面遷移の途中でボタンが押せなかったり、決済処理への受け渡しで止まったりすることはある。そうした利用者目線の不具合を拾えるのが、E2Eの強みである。

　とはいえ、全部をE2Eにすればよいわけではない。代表的な考え方に「テストピラミッド」がある。マイク・コーン氏が著書『Succeeding with Agile』で示したもので、細かく速いテストを土台に数多く用意し、粒度の大きいテストほど数を絞るという発想だ。この考え方を解説した記事は、E2Eテストは不安定になりやすく、予期せぬ理由で失敗しがちだと指摘する。一方で、ピラミッドの呼び名や形を厳密に守る必要はないとも述べている。

　また、米グーグルのテストブログでは、2015年に単体70％、結合20％、E2E10％という配分が目安として示された。もっとも、これも1つの考え方であり、どのシステムにも当てはまる正解ではない。


　つまり、E2Eは単体・結合テストより優れているわけでも、劣っているわけでもない。原因を素早く特定しやすい下位のテストと、利用者目線で全体を確かめるE2Eを組み合わせ、役割を分担させることが重要になる。

CI/CDにE2Eテストをどう組み込む？ 自動化の流れ

　E2Eテストの価値が高まるのは、CI/CDと組み合わせたときだ。CI/CDは、コードの統合からテスト、リリースまでを継続的に自動化する開発手法を指す。人手で毎回E2Eを実行するのは負担が大きいため、変更のたびに自動で走らせる仕組みに組み込む考え方が広がっている。

　典型的な流れはこうだ。開発者がコードを変更すると、まずビルド（プログラムを実行できる形にまとめる作業）が行われ、単体テストや結合テストが走る。それらを通過した後にE2Eテストを実行し、問題がなければ本番環境などへデプロイ（配置）する。速いテストを先に回し、時間のかかるE2Eを後段に置くことで、問題を早い段階で見つけやすくなる。

E2Eは万能ではない、自動化に潜む4つの落とし穴

　ただし、自動化すれば安心というわけではない。最初の落とし穴は、テストを書いたのにそもそも起動していないことだ。冒頭の例に加え、GitHub Actionsの公式ドキュメントは、条件によってスキップされたジョブが「成功」として扱われ、必須のチェックでもマージを止めないと明記している。テストが成功したことと、予定したテストが実行されたことは同じではない。


　2つ目は、同じコードなのに成功したり失敗したりする「Flaky Test（不安定なテスト）」だ。グーグルは2016年、全テスト実行の約1.5％がFlakyな結果を示し、テストの約16％に何らかの不安定さがあると公表した。こうした失敗が続くと、開発者は本物の不具合まで見過ごしやすくなる。Playwrightのように、再実行で成功したテストを「flaky」として区別するツールもある。

　3つ目は、E2Eを増やしすぎてCI/CDそのものが遅くなる問題である。E2Eは実際にブラウザを動かすため、1本あたりの時間が長くなりやすい。Playwrightのシャーディング機能のように、テストを分割して並行実行する工夫はあるが、数を増やせば待ち時間とコストも膨らむ。

　4つ目は、外部サービスやテストデータへの依存だ。決済や認証など外部のサービスが止まったり、前のテストが残したデータで状態が変わったりすると、アプリに問題がなくてもE2Eは失敗する。Playwrightは通信を差し替える「モック」機能を備え、外部の影響を切り離す手段を用意している。

　E2Eは、ユーザー視点で一連の動作を確かめる有力な方法の1つにすぎない。すべてをE2E化するのではなく、購入や申し込みなど止まると影響の大きいユーザーフローを選び、ほかのテストと組み合わせて守る。そのうえで、テストが本当に動いたかまで見届けることが、自動化を形骸化させない鍵となる。