WebDriver BiDi - クロスブラウザ自動化の未来

Jecelyn Yeen

Maksim Sadym

以前の記事では、既存の自動化プロトコルである WebDriver Classic と Chrome DevTools Protocol（CDP）と、それぞれの利点と制約について説明しました。

次は、ブラウザの自動化機能である WebDriver BiDi です。これは現在開発中の新しい標準のブラウザ自動化プロトコルで、WebDriver「Classic」と CDP の両方の長所を組み合わせることを目的としています。WebDriver BiDi は双方向通信を保証しており、デフォルトで高速通信を実現します。また、低レベルの制御も組み込まれています。

WebDriver BiDi の背後にあるビジョンは、お気に入りのツールを使用してテストを作成し、任意のブラウザまたはドライバで自動化して、最大限の柔軟性を実現できるようにすることです。

標準化

WebDriver BiDi Working Group は、さまざまなブラウザ ベンダー、オープンソースのブラウザ自動化プロジェクト、ブラウザ自動化ソリューションを提供する企業で構成されています。このコラボレーションにより、ブラウザ自動化の有望な未来が約束されます。

作業のほとんどは、こちらの GitHub リポジトリで行われます。大手ブラウザ ベンダー各社との月 1 回ミーティングが開催され、実際の進捗状況を報告し、議論の余地がある、あるいは未知の具体的な事項について議論しています。会社をまたぐワーキング グループは、すべての関係者と調整が行き渡るように調整します。

新しいプロトコルの確立と実装は決して容易ではありません。そのためには、さまざまなベンダーが協力して協力する必要があります。このプロセスには以下の操作が含まれます。

• 仕様: 提案に関するフィードバックを収集するためのコメント依頼（RFC）プロセス。
• 検証: プラットフォームをまたいで実行できる一連のテスト。すべての実装で信頼できる情報源として機能します。
• 実装: ブラウザは仕様に沿ってプロトコルを実装し、検証テストに合格します。

課題

このセクションでは、互換性、ユーザビリティ、実装性のバランスを取ることを目指し、WebDriver BiDi を実装する際の課題について詳しく説明します。

CDP クローンの先へ: ブラウザ間の互換性の活用

Chrome 固有の要素と DevTools 固有の要素を持つ CDP を、WebDriver BiDi 仕様で直接複製することはできません。他のブラウザでは、CDP をそのまま実装することは不可能であり、実装方法を文書化した仕様では意味がありません。

低レイテンシの確保

WebDriver BiDi は、パフォーマンスを犠牲にすることなく高いレイテンシを処理するように設計する必要があります。CDP では、クライアントとサーバーがほぼ常に同じ物理マシンで実行されるため、レイテンシが低くなりますが、WebDriver BiDi ではそうなりません。そのため、WebDriver BiDi は、クライアントとサーバー間で必要なラウンドトリップ回数を最小限に抑える必要があります。

BiDi での人間工学の優先順位付け

デベロッパーが WebDriver BiDi クライアントをゼロから構築することは求められませんが、プロトコルを複雑にしすぎないようにすることが重要です。BiDi が複雑すぎると、実装が困難になるだけでなく、作業も難しくなるため、導入と利用が妨げられます。

BiDi の実装可能性を確保する

WebDriver BiDi は、さまざまなブラウザの制限を考慮し、現実的に実装可能である必要があります。たとえば、BiDi によってクライアントに公開された JavaScript オブジェクトをすべて保持すると、メモリリークが発生する可能性がありますが、何も保持しないと、ページの JavaScript のデバッグや操作の妨げとなります。パフォーマンスを犠牲にすることなくブラウザを効果的に自動化するには、バランスをとることが重要です。

課題の克服

このセクションでは、WebDriver BiDi を実装する際の課題に対処するための戦略について説明します。

迅速なプロトタイピング

BiDi の成功には、実装可能性の課題への対処が不可欠です。仕様とテストの進捗を加速するため、NodeJS を使用したラピッド プロトタイピングのアプローチを採用しました。これにより、さまざまなソリューションを試すことができるだけでなく、ウェブ プラットフォーム テストの開発も容易になります。

パフォーマンスを考慮した設計

WebDriver BiDi ではレイテンシが高くなる場合があるため、この設計上の決定はパフォーマンスによって決まります。たとえば、ブラウザからオブジェクト ID と値を取得する場合、WebDriver BiDi では 1 回のラウンドトリップしか必要ありませんが、CDP では 2 回のラウンドトリップが必要です。これは、WebDriver BiDi は単一のレスポンスで ID と値の両方を返すことができるのに対し（結果は JSON でシリアル化可能にできません）、CDP はそれらを個別に返す必要があるためです。

ウェブ プラットフォーム テスト（WPT）の重視

BiDi の取り組みでは、ウェブ プラットフォーム テストが重要な役割を果たしています。現在、WebDriver Classic と WebDriver BiDi を対象としている WPT は、すべての実装で信頼できるリファレンスとして機能しています。このテストは、さまざまな実装にまたがって実行および渡されるように設計されているため、WebDriver BiDi の成功に不可欠な、ブラウザ間での一貫したプロトコル実行が保証されます。ダッシュボードで最新の WPT の結果をご確認ください。

計画と現在の進捗状況について教えてください。

プロジェクトの方向性については、WebDriver BiDi ロードマップをご覧ください。このロードマップは現在進行中であり、継続的に進化しています。

各種ブラウザの実装ステータスについては、最新のウェブ プラットフォームのテストをご覧ください。このテストが信頼できる情報源となります。

プロジェクトのマイルストーンを確認して、進捗状況を確認します。

2023 年の実績と最新の開発状況をご確認ください。

WebDriver BiDi のサポート: お客様を支援する方法

WebDriver BiDi によるブラウザ自動化の未来に期待していますか？次の方法で、応援の気持ちを示すことができます。

• 早期テスターおよびアドプターとして、WebDriver BiDi の未来を形作ってください。
• ソーシャル メディアでハッシュタグ #WebDriverBiDi を付けてプロジェクトを共有してください。
• サポートを依頼します。機能リクエストを提出するか、WebDriverBiDi の採用計画についてお気に入りのツールを確認してください。
• RFC に参加し、API に関するフィードバックを提供する。

よくある質問

Chrome DevTools Protocol（CDP）は WebDriver BiDi に置き換わるのですか？

いいえ。Chromium ベースのブラウザは、デバッグ目的で引き続き CDP を使用しますが、WebDriver BiDi は、人間工学に基づいた API でテストのニーズに対応するための新しい仕様です。

Puppeteer は CDP を使用しているため、Puppeteer のサポートは終了しますか？

いいえ。ただし、WebDriver BiDi により、Puppeteer はブラウザをまたぐ自動化ツールになります。

公開ロードマップはありますか？

はい、GitHub のロードマップをご覧ください。