こんにちは！みなさん、テストしてますか？
第2回の前編では、E2Eテストの基幹部分とも言える要素探索の技術の変遷について扱い、中編では 実装 の技術の変遷について扱いました。
後編では、どのようにブラウザを介してWebアプリケーションを自動操作するのか、つまり自動操作技術について触れたいと思います。また、UIを自動操作して実施するテストという点から、E2Eテストには良くも悪くも様々な目的が期待されてしまっていましたが、これらはWebアプリケーション開発技術の変遷と共に徐々に変わってきました。こうしたE2Eテストの目的についても触れたいと思います。
記事一覧：モダンなE2Eテストの考え方をマスターしよう
自動操作技術の変遷
さて、この連載では一貫してPlaywrightを使っています。PlaywrightはいわゆるE2Eテストフレームワークですが、大きく分けると「Webブラウザを自動操作するコンポーネント」と「自動テストを記述するコンポーネント」で成り立っています。
このうち、「自動操作」のほうには様々な変遷がありました。あまりに古いものは自分も良く知らない部分が多いので、おおむね2016年以降の主要なマイルストーンについて記載します。
- Selenium 3 と Webdriver
- CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行
- 開発者体験を重視したツールの流行
Selenium 3 と Webdriver
Seleniumは、2025年現在で利用できるものの中では、もっとも歴史の長いブラウザ自動操作ライブラリです。複数のブラウザを統一されたAPIで自動操作できる、というのが強みで、たくさんのテストケースをたくさんのブラウザインスタンス上で実行するためのインフラも用意しています。
クロスブラウザの複雑性をライブラリ側で吸収するというアイディアと、ブラウザとSelenium Serverの中継ぎをするWebDriver部分は仕様を公開して各ブラウザベンダーに実装を任せるという思想そのものは良かったのですが、自動テストインフラの複雑さを招くことにもつながり、インフラの構築やメンテナンス、テスト実行時のトラブルシューティングなどの別の辛さを招いてしまうことも多かったです。
加えて、Selenium WebDriverの（少なくとも当時の）設計思想は「UI上で実際にユーザーが可能なインタラクションを模倣する」というものだったため、テストのためのモック/スタブを作りにくかったり、ネットワークスロットリングなどで特殊な環境を再現した上でのテストが難しいという弱点もありました。
また、仕組み上全てがHTTPベースのコミュニケーションになってしまう点もパフォーマンス上問題になるケースが多く、特にページロードや要素の表示待ちなどが非常に長くなるケースがありました。当時E2Eテストに「不安定」「遅い」という印象を持っていた人たちは、おそらくこれらに苦しめられたいたことでしょう。
一方で、色々と問題はありつつも、自動テストのための大統一APIを作るというビッグピクチャーに向けて今もなお前進し続けているプロジェクトであることは疑いの余地はなく、自動テストエンジニアとして生きるならぜひ動向を追い続けたいプロジェクトの一つです。
ちなみに、HTTPベースの単方向通信しか出来なかったのを改善するために、新しくWebDriver BiDiという仕様が策定されています。こちらについては後述します。
CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行
ChromeがHeadlessモードをサポートしたことと、CDP（Chrome DevTools Protocol）をテストに使うことでSeleniumの弱点をカバーできると考えて、CDPをベースにしたハイレベルAPIを実装したのがPuppeteerです。当初はCDPを使っていたのですが、現在は後述するWebDriver BiDiを用いています。
Seleniumがあくまでユーザーに出来る操作のみにフォーカスしていたのに対し（参考：Selenium使いのためのPuppeteer解説｜Qiita ）、PuppeteerはCDPを用いるためネットワーク速度のスロットリングやスタブなど様々な開発者向け機能に対応しており、テストしやすさを改善していました。
一方で、Seleniumユーザーたちの多くがJavaやPythonなどでテストコードを書いていたのに対して、PuppeteerはJavaScriptのみの対応でした。これは普段UIを扱うフロントエンドエンジニアたちには自然だった一方で、JavaScriptの非同期APIに慣れ親しむ前の自動テストエンジニアたちにとってはかなり悩みのタネで、筆者も「自動テストスクリプトが順番通りに動いてくれない……おれはただテストを自動化したいだけなのに……」と毎日悪戦苦闘していたのを覚えています。
ちなみに、パフォーマンスの点について公平のために補足しておくと、Chrome/Chromiumブラウザの自動操作を担うWebDriver実装であるChromeDriverもまたCDPベースで実装されています。ですが、やはりWebDriver自体の通信がHTTP通信であることによるオーバーヘッド自体が大きかったため、速度の面でPuppeteerの方が有利でした。
また、SeleniumとPuppeteerの大きな違いとして、Selenium Gridのような大規模テストインフラを構築する機能の有無がありました。これは大量の実機テスト実行環境を束ねる目的では重要なのですが、CI/CD環境の中でChromiumをインストールしてテストを回すようなケースではそもそも不要なものでもありました。
開発者体験を重視したツールの流行
Cypress
さて、Puppeteerの登場で、あくまで筆者の肌感ではあるものの、自動テスト界隈の人気は二分された印象がありました。
- テストコードが書けるたくさんのテストエンジニアを中心にたくさんの自動テストを実行したい→Selenium
- 開発者が日常の開発サイクルの中でガンガンE2Eテストを回していきたい→Puppeteer
そうすると、開発者はどうしても開発者体験の良さに目が行ってしまいます。例えば、ドキュメントが豊富であるとか、コードが書きやすいとか、デバッグ用のツールキットが充実しているとか、普段の開発エコシステムの中に組み込みやすいとか、そういった具合です。
そんな中で登場したのがCypressです。Cypressははフロントエンドの開発体験をウリにしたツールで、当時の開発者たちが慣れ親しんでいたjQueryのメソッドチェーンを踏襲した書きやすいAPI、フロントエンドエコシステムとの親和性、デバッグ体験の良さなど、良いところがたくさんありました。
一方で、仕組み上複数タブ・ウィンドウの切り替えが出来ないことや、クロスドメインiframeがテストできないことなどは、テスト対象のウェブサイトによっては致命的でした。ちなみに、Cypressのドキュメントは本当に徹底していて、これらのトレードオフまでつまびらかに解説されています。
Cypress docs：https://docs.cypress.io/app/references/trade-offs
こうした課題はありつつも、上述した開発者体験の良さ、ならびにこうしたトレードオフまで充分に解説されたドキュメントなどは非常に開発者フレンドリーで、多くの開発者たちに親しまれていました（余談ですが、筆者はあるオンラインカンファレンスでCypressの中の人が「ドキュメントが充実しているのもCypressのいいところで、困ったことがあったらCommand+Kで一発で検索できる」と誇らしげに語っているのを見て、とても良いことだなと感心した覚えがあります）。
Playwright
さて、Cypressのメジャーリリースとほぼ同時期に、本連載でも使っているPlaywrightがα版として産声を挙げました。自動操作の方法としてはPuppeteerが使っているCDPというものになるのですが、この方法は名前の通りChromium系のブラウザ（Chrome、Chromium、Edge）でしか使えないので、FireFoxやSafariはテスト用にビルドしたものを使っています。
個人的には非常にバランスの取れた、良い意味でいいとこ取りのツールだと捉えています。開発者体験の観点からCypressと人気を二分していましたが、その後Cypressと似た機能を取り入れることでより強力なツールになりました。
余談: Selenium4・Webdriver-BiDi
冒頭で紹介したSeleniumですが、何となくオワコンのように見えてしまいがちですが、きちんとメンテナンスされ続けており、2022年には待望の新メジャーバージョンが登場しました。本記事のPuppeteerの項目で「PuppeteerはCDPを直接触れるのでテストが楽」というようなことを書きましたが、Selenium4は待望のcdp エンドポイントが実装され、ブラウザによりますがCDPによる豊富なデバッグ機能にアクセスできるようになりました。
また、Seleniumの根幹となるWebdriver規格も進化しており、新たにWebdriver-BiDiというものが提案されています。BiDiはBiDirectional、つまり双方向の略です。SeleniumがHTTPベースの単方向通信のみのツールだったのを、Webdriver-BiDiはWebsocketベースの双方向通信のものに変えています。これにより、ページの表示待ちなどのパフォーマンスが改善しました。
Puppeteerの話の中で触れたとおり、現在PuppeteerはCDPベースからWebdriver-BiDiベースに変わっています。これがより進んでいくと、クロスブラウザテストのやりやすさはより高くなっていくはずです。
目的/役割の変遷
さて、この「E2Eテストの歴史」は、主にE2E自動テストで使われる技術の変化にスポットを当てることで、「本/記事によって書いてあることが全然違う」という状態を解きほぐすことを目的にしていました。締めくくりとして、これらの技術が何に対して使われるのかの変遷についても理解しておきましょう。
手続き的UIの時代: UIテスト = E2Eテスト
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
