Mozilla HacksのImproving Cross-Browser Testing, Part 1: Web Application Testing Todayを読みました。Webアプリのテスト自動化が、WebDriverの標準化された安定性と、DevToolsプロトコルの低レベルな柔軟性の間で揺れていることを整理した記事です。
Webアプリは、OS、ブラウザ、端末、画面サイズがばらばらな環境で動きます。MDN Developer Needs Assessmentでも、クロスブラウザテストは開発者の大きな痛点として挙げられていました。この記事は、なぜその痛みが残り続けるのかを、ツールの歴史とプロトコルの設計から説明しています。
記事の要点
- 現在のクロスブラウザ自動テストの中心には、W3C標準のWebDriverがあります。
- WebDriverはHTTPベースの同期的なコマンド/レスポンスモデルで、Seleniumの流れをくむ分かりやすい仕組みです。
- Firefoxでは geckodriver がWebDriverメッセージをGeckoのMarionetteプロトコルへ変換し、ChromeDriverやSafariDriverも同様にブラウザ固有の内部プロトコルへ橋渡しします。
- HTTPベースのWebDriverは安定していて大規模運用しやすい一方、ログやネットワークイベント、突然出るアラートのような非同期イベントを扱いにくい弱点があります。
- DevToolsプロトコルは双方向通信なので、コンソールログやネットワークイベントをリアルタイムに受け取れます。ただし、ブラウザ内部実装に近く、エンジンごとに差が大きくなります。
- Puppeteer、Playwright、Cypressのようなツールは、WebDriverだけでは難しい機能を提供するためにDevTools系の仕組みへ寄っています。
参照リンクから見えたこと
WebDriver仕様を確認すると、WebDriverはブラウザを外部プロセスから制御するための、プラットフォームにも言語にも依存しにくいワイヤープロトコルとして定義されています。SeleniumやSelenium Grid、Sauce Labs、BrowserStackのような大規模なリモート実行基盤と相性がよい理由もここにあります。
一方で、PlaywrightやCypressのような近年のテストツールを見ると、開発者が求めるのは単なるクリックや入力だけではありません。ネットワークの差し替え、コンソールログの取得、ブラウザ内部状態に近い情報、非同期イベントの観測など、よりフロントエンド開発に近い体験が求められています。
記事が示している問題は、機能を求めるとブラウザ固有のDevToolsプロトコルに近づき、ブラウザ横断性を求めるとWebDriverの枠に戻る、という緊張関係です。この緊張が、後のWebDriver BiDiやFirefoxのPuppeteer対応につながる背景になっています。
気づき
今回の気づきは、テスト自動化の標準化は「操作できるコマンドを増やす」だけでは足りないということです。Webアプリが非同期イベントだらけになった以上、テストプロトコルもブラウザから自発的にイベントを送れる必要があります。ただし、それをブラウザ固有の内部APIとして広げると横断性が壊れます。だから、WebDriver BiDiのような標準化された双方向プロトコルが必要になったのだと理解できます。
コメントを残す