ケーススタディ - WebdriverIOがオンライン動画配信企業のリリース速度向上とコード品質改善に貢献

2021年6月22日 ·5 分で読めます

JW Playerは、毎日10億回以上のユニークビューを生成する、埋め込み可能なオンラインビデオプレーヤーです。この規模を維持し、成長させるためには、プレーヤーは多数の異なるWebおよびモバイルプラットフォームで機能できる必要があります。そのため、多くの異なるターゲットにデプロイする際のリリースに対する信頼を高めるために、自動テストの重要性が高まります。6,000以上のテストで構成されるレガシーテストフレームワークからの移行という長期プロジェクトの後、JW Playerのテストエンジニアリングチームは、よりタイムリーなリリースを、より少ない回帰で提供できるようになりました。WebdriverIOのおかげで、大きなロールバックは発生せず、自社製品の品質に対する信頼が高まりました。

WebdriverIOの選択

WebdriverIOに移行する前は、Cucumberの上にオープンソースのRubyフレームワークを使用していました。JW Playerは、7つのデスクトップおよびモバイルWebブラウザ、そしてそれぞれ10と4.4に遡るiOSおよびAndroidバージョンで公式にサポートされています。これらのプラットフォームのカバレッジのために、毎晩約25,000件のUI受け入れテストを実行しています。レガシー実装では2つの問題が発生しました。第一に、すべてのプラットフォームで単一のテストを実行すると最大9時間かかるため、Rubyのパフォーマンス制限に遭遇しました。第二に、プレーヤーはJavaScriptで実装されているため、製品エンジニアはRubyベースのフレームワークを採用して貢献する可能性が低くなりました。JavaScriptネイティブのフレームワークに移行することで、これらの両方の問題に対処しました。

Selenium Webdriverは、長い間Web自動化の定番となってきました。2018年頃、私たちのチームはいくつかの新しいテスト技術の探求を始めました。Cypressはブラウザのサポートが限られており、Microsoft Playwrightはまだリリースされておらず、PuppeteerはChromeでのみ実行されます。ブラウザベンダーの間で幅広く専用のサポートを受けているWebdriverベースのソリューションが、明らかに勝者でした。

当初WebdriverIOに惹かれたのは、その分かりやすいAPIと、必要なすべてのブラウザとデバイスの完全なサポートでした。CypressやPuppeteerは、必要なプラットフォームの1つ以上をサポートしていません。しかし、さらに重要なのは、その豊富なプラグインシステムと活発で熱心な開発者コミュニティでした。テスト分野で既に名を馳せているSauce Labsからのスポンサーシップは、WebdriverIOが成長を続け、放棄されるソフトウェアにならないという自信を与えてくれました。

WebdriverIOは、すぐに使える状態で、既存および必要なツールセットのいくつかをサポートしていました。製品の欠陥をすばやく洗い出すために使用するAllureレポートや、テストの健全性を監視し、経時的な傾向を追跡するために使用するReport Portalなどのツールは、簡単に統合できました。きめ細かい実行前後のフックにより、テストエンジニアはテストの実行方法と場所をかつてないほど自由に設定できるようになりました。

Webdriver.IOの実践的なアプローチ

WebdriverIOに機能が追加され続けるにつれて、オープンソースの依存関係や乱雑なmixinコードを削除することで、コードベースを継続的に簡素化することができます。古いフレームワークが依存していたサービスを完全に廃止することさえできました。

昨年リリースされたネットワークプリミティブ機能により、HTTPリクエストを傍受および操作するためにSelenium Webdriverアプリケーションで一般的に使用されるプロキシツールであるBrowsermob Proxyへの依存関係を削除することができました。 अब हम browser.mock() को कॉल करते हैं, उस अनुरोध के सबस्ट्रिंग या रेगेक्स को निर्दिष्ट करते हैं जिसे हम कैप्चर करना चाहते हैं और एसेट को बदलने के लिए एक साधारण मॉक ऑब्जेक्ट प्रदान करते हैं. 応答を遅延させる機能により、手動実行が必要だったいくつかの複雑なテストを自動化することができました。その後、広告などの特定のリクエストがネットワークまたはその他の外部条件によって遅延された場合のプレーヤーの動作を検証することができました。
```
// mock.js
export function delayResponse3seconds() {
    return new Promise((resolve) => setTimeout(() => {
        return resolve('{ "foo": bar }');
    }, 3000));
}

// test.js
import { delayResponse3seconds } from './mock';

function rewritePattern(pattern, replacement) {
   console.log(`Attempting to rewrite: ${pattern} with: ${replacement}`);
   const toRewrite = browser.mock(`**/${pattern}`);
   toRewrite.respond(delayResponse3seconds);
   console.log(`Successfully rewrote ${pattern} to ${replacement}`);
}
```
すぐに使用できるChrome Devtoolsプロトコルのサポートにより、手動で行っていた面倒なテストをいくつか自動化することができました。初期ページの読み込み後に browser.throttle(“Good3G”) を呼び出せるようになったことで、モバイルユーザー向けにより現実的な条件下でのビデオプレーヤーの動作をより正確に検証できるようになりました。
WebdriverIOのCDPマッピングのおかげで、一連のパフォーマンステストを作成および維持することができました。ページの読み込み後に browser.getMetrics() を呼び出し、プレーヤーと対話することで、プレーヤーがセットアップされ、顧客のWebサイトに埋め込まれたら、エンドユーザーに混乱を招くページ読み込みエクスペリエンスを作成する過度の累積レイアウトシフトが発生しないことを検証できるようになりました。

まとめ

全体的に、JW PlayerのWebdriverIOへの移行は大成功でした。古いフレームワークに比べてパフォーマンスと「生活の質」が向上したことに加えて、WebdriverIOの機能セットにより、数百の手動テストケースを自動化することができました。回帰サイクルの長さを約1週間からわずか数日に大幅に短縮することができました。しかし、最も重要なことは、これらの改善により、記録的な数の欠陥を発見することができ、より高品質な製品とより多くの顧客価値を提供できるようになったことです。

WebdriverIOの選択​

Webdriver.IOの実践的なアプローチ​

まとめ​

WebdriverIOの選択

Webdriver.IOの実践的なアプローチ

まとめ