過去を振り返って: テスト自動化の進化

Jecelyn Yeen
Maksim Sadym
Maksim Sadym
X GitHub

テスト自動化の登場

ウェブブラウザが誕生した 1990 年代に話を戻しましょう。テストの自動化が実現したのは 2000 年代に入ってから、ブラウザをまたいだマルチデバイスのテストの課題に取り組む Selenium や WebDriver プロジェクトの登場です。

この 2 つのプロジェクトは 2011 年に Selenium WebDriver として連携し、2018 年には W3C 標準となりました。通常は WebDriver または WebDriver Classic と呼ばれます。

Selenium WebDriver プロジェクトの進化。
Selenium WebDriver プロジェクトの進化

WebDriver が「Classic」の前のテスト自動化は、かなり複雑でした。ブラウザのテストを自動化できるようになったことで、デベロッパーとテスターの生活の質が大幅に向上しました。

JavaScript の台頭

ウェブ開発が JavaScript への依存度を高めるにつれ、WebdriverIO、Appium、Nightwatch、Protractor（非推奨）、Testcafe、Cypress、Puppeteer、Playwright などの新しい自動化ソリューションが登場しました。

JavaScript 自動化ツール。
JavaScript 自動化ツール

自動化のアプローチ

これらのツールは、ブラウザを自動化する方法に基づいて、大きく 2 つのグループに分けることができます。

  • 概要: ブラウザ内で JavaScript を実行するツール。たとえば、Cypress と TestCafe は、ウェブ API と Node.js を利用して、ブラウザ内で直接テストを実行します。興味深いことに、Selenium の最初のバージョンでも同じアプローチが使用されていました。
  • 低レベル: ブラウザの外部でリモート コマンドを実行するためのツール。複数のタブを開く、デバイスモードをシミュレートするなど、ツールでさらに細かい制御が必要な場合は、リモート コマンドを実行してプロトコルを介してブラウザを制御する必要があります。 主な自動化プロトコルは、WebDriver Classic と Chrome DevTools Protocol（CDP）の 2 つです。

次のセクションでは、これら 2 つのプロトコルを見ながら、それぞれの長所と制限を理解します。

WebDriver Classic と CDP。

WebDriver Classic と Chrome DevTools プロトコル（CDP）の比較

WebDriver Classic は、すべての主要なブラウザでサポートされているウェブ標準です。自動化スクリプトは、HTTP リクエストを介してドライバ サーバーにコマンドを発行します。ドライバ サーバーは、ブラウザ固有の内部プロトコルを介してブラウザと通信します。

クロスブラウザのサポートに優れており、API はテスト用に設計されていますが、処理に時間がかかる場合があり、一部の下位レベルの制御には対応していません。

WebDriver Classic。
WebDriver「Classic」

たとえば、要素 await coffee.click(); をクリックするテスト スクリプトがあるとします。これは一連の HTTP リクエストに変換されます。

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

一方、Chrome DevTools プロトコル（CDP）は、当初は Chrome DevTools とデバッグ向けに設計されましたが、自動化のために Puppeteer に採用されました。CDP は WebSocket 接続を介して Chromium ベースのブラウザと直接通信し、より高速なパフォーマンスと低レベルの制御を実現します。

ただし、この機能は Chromium ベースのブラウザでのみ機能し、オープン スタンダードではありません。そのうえ、CDP API は比較的複雑です。CDP との連携が、人間工学的に不適切な場合もあります。たとえば、プロセス外の iframe を操作するには多大な労力がかかります。

CDP。
Chrome DevTools プロトコル

たとえば、要素 await coffee.click(); をクリックすると、一連の CDP コマンドに変換されます。

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

下位レベルのコントロールとは？

WebDriver Classic が開発されたときは、低レベルの制御は必要ありませんでした。しかし、時代が変化し、ウェブの能力が格段に向上し、テストにはきめ細かなアクションが必要になりました。

CDP はすべてのデバッグのニーズをカバーするように設計されているため、WebDriver の「Classic」よりも低レベルの制御をサポートしています。CDP は次のような機能を処理できます。

  • コンソール メッセージのキャプチャ
  • ネットワーク リクエストのインターセプト
  • デバイスモードのシミュレーション
  • 位置情報のシミュレーション
  • など多数

WebDriver の「Classic」では、アーキテクチャが異なるため、これらを行うことはできませんでした。WebDriver の「Classic」は HTTP ベースであるため、ブラウザのイベントのサブスクライブやリッスンは困難です。一方、CDP は WebSocket ベースであり、デフォルトで双方向メッセージングをサポートしています。

次のステップ: WebDriver BiDi

WebDriver「Classic」と CDP の強みを以下にまとめます。

WebDriver「Classic」 Chrome DevTools プロトコル（CDP）
最適なクロスブラウザ サポート 高速な双方向メッセージ
W3C 標準 下位レベルの制御を提供
テスト用に作成

WebDriver BiDi は、WebDriver「Classic」と CDP の長所を組み合わせることを目的としています。現在開発中の新しい標準ブラウザ自動化プロトコルです。

WebDriver BiDi プロジェクトの仕組み、ビジョン、標準化プロセスの詳細をご覧ください。