Mozilla HacksのImproving Cross-Browser Testing, Part 2: New Automation Features in Firefox Nightlyを読みました。前回紹介したWebアプリテストの現状編に続き、Firefox NightlyでPuppeteerやSelenium 4から使えるようになった新しい自動化機能を紹介する記事です。
Part 1では、WebDriverの安定した標準性と、DevToolsプロトコルの双方向・低レベルな柔軟性の間にある課題が整理されていました。Part 2では、そのギャップを埋めるために、Firefox NightlyがPuppeteerやSelenium 4とどう接続し始めたのかが説明されています。
記事の要点
- PuppeteerはChrome DevTools Protocolを前提に発展したツールですが、Firefox Nightlyでも利用できるようにする取り組みが進められていました。
npm install puppeteerでFirefox Nightlyを取得し、product: 'firefox'を指定して起動する形が紹介されています。- Selenium 4でも、DevTools由来の機能を使えるようにする動きがあり、Firefox側ではRemote Protocolを通じて接続します。
- Firefox Nightlyでは
--remote-debugging-portを使ってリモートデバッグ用のポートを開き、自動化クライアントから接続します。 - ただし、記事はこの時点の実装を最終形とはしていません。最終的には、ブラウザ横断の標準としてWebDriver BiDiへ向かう流れが示されています。
- 問題報告先としてPuppeteerのissue tracker、Bugzilla、Matrixのremote-protocolチャンネルも案内されており、開発中の機能としてフィードバックを集めていました。
参照リンクから見えたこと
Puppeteerは、ブラウザ自動化を開発者体験に近いAPIで扱えるツールです。記事中のcross-browser exampleや、Firefox対応状況を示すページは、当時のFirefox対応がまだ段階的なものだったことを示しています。
Selenium 4は、従来のWebDriver資産を持つ利用者にとって重要です。記事がPuppeteerとSeleniumの両方を扱っているのは、新しいDevTools系機能を使いたい層と、既存のWebDriver/Selenium資産を持つ層の両方を橋渡しするためだと読めます。
WebDriver BiDi仕様も確認しました。従来のWebDriverがコマンド/レスポンス中心だったのに対し、BiDiはブラウザからイベントを流せる双方向プロトコルです。この記事時点のFirefox Nightly対応は、その完成形へ向かう実験的な通路だったと言えます。
気づき
今回の気づきは、標準が完成してから実装するのではなく、Nightlyで先に開発者と接続し、実際のツールからフィードバックを得ながら標準へ近づけている点です。Puppeteer対応もSelenium 4対応も、単なる互換機能ではなく、WebDriver BiDiへ向けて実利用の要求を集めるための足場になっていました。
コメントを残す