次世代のブラウザテスト自動化プロトコルWeb Driver BiDi
W3Cにて、従来のWebDriverの拡張版として言及される「WebDriver Bidirectional Protocol」(通称WebDriver BiDi)の策定が進んでおり、各ブラウザ及びツール群への実装も少しずつ始まっています。本記事では自動ブラウザテスト技術の変遷およびWebDriver BiDiによる恩恵についてまとめ、影響を受けることが予測されるツールについて考えます。
自動ブラウザテスト技術の変遷
自動ブラウザテスト技術は、大きく次の3つに分類されます。
- WebDriver型(Selenium, WebDriverIOなど)
- Native型(Cypress, TestCafe)
- CDP型(Puppeteer, PlayWright)
Browser Automation Tools Protocols – Webdriver vs CDP
WebDriver型
最も長い歴史を持つWebDriver型は、Seleniumがその代表例です。WebDriverはWebブラウザを外部から制御するための標準インターフェースを目指してたものです。Seleniumが独自に実装したWebDriverの他に各ベンダが各ブラウザに対応したそれぞれのWebDriverが存在しています。
| Browser | Driver |
|---|---|
| Google Chrome | Chrome Driver |
| FireFox | geckodriver |
| MicroSoft Edge | Edge Driver |
| safari | safari driver |
Seleniumの独自実装が元となって2018年にはW3C勧告として標準化されました。[1] 言葉の使い方が非常にややこしいのですが、ここでいうW3CのWebDriverはChrome Driver, geckodriverといった具体的な実装ではなく、ブラウザを自動化するためのAPIとプロトコルを規定したものを指しています。
Selenium4を例にとるとWebDriver型のツールは次の流れで動作しています。
- Driverに対してクライアントから自動化コマンドを送る
- Driverが実際のブラウザ操作に変換し、ブラウザを自動操作
Architecture of Selenium WebDriver
この方式はW3Cの標準が存在しクロスブラウザ対応が容易な点でメリットがあります。一方で仕組み上flakyになりやすかったり、websocketを使った実装に比べて低速であるというデメリットがあります。
Native型
2017年に登場したCypressなどのNative型は、WebDriverを使用せずにJavaScript APIを直接利用しています。
Cypressを例にとるとアーキテクチャは次のようになっています。
テストランナー自体が実際のブラウザ内で動作しておりiframeを通じてロードしたテスト対象のアプリケーションを直接操作することでUIのテストを行います。
SeleniumなどでWebDriverが担っていた部分は、簡単にいうとiframeのcontentWindowを引っこ抜いてDOMにアクセスし、独自Driver(ちょっとだけ拡張したjQuery)で操作していると思われます。
CDP型
Puppeteerや最近人気のPlaywright[2]がこの方式です。これらのツールはもとは名前の通り開発者ツール用に作られているChrome DevTools Protocol(通称CDP) を利用しています。
例としてPlaywrightのアーキテクチャを示します。
WebDriver型と似ていてクライアントからのリクエストをCDPコマンドに変換してブラウザを操作します。クライアント、サーバー間はwebsocketで通信により高速で動作し、コマンドを送信すると同時にサーバーからのイベント/メッセージをリアルタイムでリッスンできます。
また、CDPは低レベルなAPIにもアクセスできるため、consoleのキャプチャやDOMの監視、ネットワークのinterceptなど低レベルな制御が可能です。
話はそれますが、CDPは結構面白いことができます。具体的な使用例として次の記事が参考になると思います。
しかし、このCDP型にもいくつか欠点があります。まずChromium baseのブラウザでしか動作しません。Puppeteerは試験的にFirefoxに対応していますが、これはFirefoxに実装されているremote protocolというCDPのサブセットを利用したものであり、完全な互換性はありません。[3]
また、PlaywrightもFirefoxやsafariが動かせますが、FireFox、Safariの特定のバージョンに何かしらのパッチを当てて動かしています。
またGoogle Chromeの新バージョンのリリースごとにCDPの新バージョンがリリースされるため、互換性の問題があります。特定の機能が変更されることで、テストコードが将来のブラウザのバージョンでは機能しなくなる可能性があります。
Web Driver BiDi
やっと本題です。これらの背景を踏まえた上で、W3CのBrowser Testing and Tools Working GroupにでWebDriver BiDiの策定が進んでいます。
Working Groupには主要なブラウザベンダー(Chrome、Edge、Safari、FireFox)、テストフレームワークの開発チーム(Selenium、WebDriver IO)、関連SaaS(BrowserStack、SauseLabs、LAMBDATEST)が参加しています。
このプロトコルは簡単にいうとWebDriver型とCDP型のいいとこどりをしてしまおうというものです。すなわち、
- クロスブラウザ対応
- W3C準拠
- 高速
- 低レベルな操作にも対応
なものを目指したprotocolです。
このprotocolは local end(クライアント) と remote end(ユーザーエージェント) 間のの双方向の通信プロトコルの定義をはじめとしてsession管理やlocal-remote間のコマンド、イベント、エラー定義などが含まれています。
この仕様に基づき各ブラウザ側の実装も進んでおり、web platformテストで進捗が確認できます。ChromiumとEdgeはすでに多くのテストケースが通過しています。Firefoxも着実に進んでいることがわかります。Safariはまだ時間がかかりそうです。
2024年3月現在、W3C勧告までには達していませんがPuppeteerやwebdriverIOといったツール側での試験的にサポートも始まっています。
SeleniumなどのWebDriver型、Puppeteer、PlaywrightのようなCDP型のツールは今後このプロトコルの実装も進んでいき、恩恵を得ることができるでしょう。
またツール内部の通信プロトコルレイヤの話であることやPuppeteerの例を見ると大規模なマイグレーションは発生せず、テストコードはそのまま利用できると思います。
一方で前述した仕組みを鑑みるとCypressをはじめとしたNative型のツールにはあまり影響がないと考えます。[4]
まとめ
- BiDiは従来のWebDriverとCDPを利用したテストツールのいいとこ取り
- 低レベルなAPIへのアクセスも可能で、高速な通信もできる
- クロスブラウザ対応が容易になる
- このProtocolの策定によって特に影響を受けるのはSelenium、Puppeteer、PlayWrightなどのツールだと思われる
- ただし大規模なマイグレーションを伴うものではない
- Cypressはあまり関係ない??
-
PlaywrightはPuppeteerのチームがMSに移籍して開発しているという話がありますが事実だと思われます。https://news.ycombinator.com/item?id=30111822 ↩︎
-
Puppeteerチームもクロスブラウザ対応させたいという野望はあったようですが、プロジェクト自体の優先度が下げられたらしくあまり進まなかった模様。https://news.ycombinator.com/item?id=30108680 ↩︎
-
ネット上にCypressもCDP対応しているという記述が結構ありましたが、テストでメインとなるDOM取得とかはCDP経由でやってない感じがしました。カスタムコマンドとかでは使えるようです。https://glebbahmutov.com/blog/cypress-automation/ ↩︎
Discussion