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

Jecelyn Yeen

Maksim Sadym

テスト自動化の誕生

ウェブブラウザが誕生した 1990 年代にさかのぼりましょう。テストの自動化は 2000 年代まで実現しませんでした。ブラウザ間やマルチデバイスのテストの課題に対処する Selenium プロジェクトと WebDriver プロジェクトが登場したことで、

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

</ph>

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

JavaScript の台頭

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

</ph>

自動化アプローチ

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

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

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

WebDriver「Classic」Chrome DevTools Protocol（CDP）との比較

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

優れたクロスブラウザ サポートを備え、API はテスト用に設計されていますが、動作が遅く、一部の下位レベルのコントロールをサポートしていません。

</ph>

たとえば、要素 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 Protocol（CDP）は当初、Chrome DevTools とデバッグ用に設計されましたが、Puppeteer によって自動化のために採用されました。CDP は WebSocket 接続を介して Chromium ベースのブラウザと直接通信するため、パフォーマンスの高速化と低レベルの制御を実現できます。

ただし、Chromium ベースのブラウザでしか機能せず、オープン スタンダードではありません。加えて、CDP API は比較的複雑です。場合によっては、CDP の操作が人間工学的に難しいことがあります。たとえば、プロセス外の iframe を扱うには多大な労力がかかります。

</ph>

たとえば、要素 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」よりも多くの下位レベルのコントロールをサポートしています。次のような機能を処理できます。

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

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

次のステップ: WebDriver BiDi

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

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

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