WebdriverIO v6 リリース
これを読んで、v5への移行に多くの時間を費やしたばかりなのでパニックになりそうになっている方はご安心ください!今回のメジャーアップデートは、昨年のものよりも「破壊的」ではありません。昨年のアーキテクチャの変更では、多くのものを壊さざるを得なかったのですが、今回は非常に慎重に進め、フレームワークのアップグレードが大きな作業にならないようにしました。
今回のメジャーアップデートはより合理的で、プロジェクトが成長を続けながら同時にパフォーマンスを維持するのに役立つ、わずかな変更が含まれています。このブログ記事では、すべての主要な変更について詳しく説明し、v5からv6への移行のために何をする必要があるかを説明します。
Node v8のサポート終了
Node.jsチームによって2020年の初めに非推奨になったNode v8のサポートを終了しました。このバージョンを使用しているシステムを実行することは推奨されません。2022年4月までサポートされるNode v12に切り替えることを強くお勧めします。
アップデート方法
Node.jsをアップデートするには、そもそもどのようにインストールされたかを知ることが重要です。Docker環境の場合は、次のようにベースイメージをアップグレードするだけで済みます。
- FROM mhart/alpine-node:8
+ FROM mhart/alpine-node:12
Node.jsのバージョンをインストールおよび管理するには、NVM(Node Version Manager)を使用することをお勧めします。NVMのインストール方法とNodeのアップデート方法の詳細については、プロジェクトのREADMEをご覧ください。
devtools
自動化プロトコルがデフォルトに
PuppeteerやCypress.ioのような自動化ツールが大きな成功を収めたため、現在の形でのWebDriverプロトコルは、今日の開発者や自動化エンジニアの要件を満たしていないことが明らかになりました。WebdriverIOプロジェクトのメンバーは、WebDriver仕様を定義するW3Cワーキンググループの一員であり、現在の最先端技術を改善するためのソリューションについてブラウザベンダーと協力しています。Microsoftのメンバーのおかげで、他の自動化プロトコル、たとえばChrome Devtoolsと同様の新しい双方向接続に関する提案がすでにあります。
新しいWebDriverアーキテクチャについてすべてのブラウザベンダーの間で合意に達するまで、プロジェクトは代替ソリューションを提供したいと考えています。そのため、同じAPIを使用してPuppeteerをネイティブにサポートし始めました。すでに昨年、サポートを発表しており、現在ではプロジェクトに完全に組み込まれています。つまり、ローカルテストスクリプトを実行するために、ブラウザドライバをダウンロードする必要はなくなりました。WebdriverIOは、ブラウザドライバがlocalhost:4444/
で実行されてアクセス可能かどうかを確認し、そうでない場合はフォールバックとしてPuppeteerを使用します。WebdriverIO APIを使用する場合、WebDriverとPuppeteerを使用するエクスペリエンスは同じはずで、Puppeteerでコマンドを実行する方が少し速くなるかもしれません。
注:WebDriverの代わりにPuppeteerを使用できるのは、ローカルでテストを実行する場合と、ブラウザがテストと同じマシンにある場合のみです。
テストでPuppeteerにアクセスできると、はるかに豊富な自動化機能を備えたChrome DevToolsプロトコルの機能を利用できます。テストでは、必要に応じてPuppeteerとWebdriverIO APIを自由に切り替えることができます。例:
describe('my e2e tests', () => {
// ...
it('replaces the WebdriverIO logo with the Puppeteer logo', () => {
browser.url('https://webdriverio.dokyumento.jp')
/**
* run Puppeteer code with promises to intercept network requests
* and replace the WebdriverIO logo in the docs with the Puppeteer logo
*/
const wdioLogo = 'webdriverio.png'
const pptrLogo = 'https://user-images.githubusercontent.com/10379601/29446482-04f7036a-841f-11e7-9872-91d1fc2ea683.png'
browser.call(async () => {
const puppeteerBrowser = browser.getPuppeteer()
const page = (await puppeteerBrowser.pages())[0]
await page.setRequestInterception(true)
page.on('request', (interceptedRequest) => (
interceptedRequest.url().endsWith(wdioLogo)
? interceptedRequest.continue({ url: pptrLogo })
: interceptedRequest.continue()
))
})
// continue with sync WebdriverIO commands
browser.refresh()
browser.pause(2000)
})
})
Chrome、Firefox(Nightly)、Chromium Edgeで「クロスブラウザ」テストを実行できるようにPuppeteerを統合しました。ここで、クロスブラウザという用語は引用符付きで使用されていることに注意してください。今日の多くの自動化ツールは、クロスブラウザサポートを宣伝していますが、それが実際に何を意味するのかについてはあまり正直ではありません。Google Chrome、Chromium Edge、Electronベースのアプリなど、すべてのChromiumベースのブラウザは、内部で同一のエンジンを使用しています。複数のChromiumベースのブラウザでテストすることにあまり価値があるかどうかは疑問です。それに加えて、Firefoxのサポートは、Mozillaのチームがその場しのぎの取り組みで実装したものであり、実験段階から脱却させ、サポートを継続することを約束していないため、実験的なものであり続けるでしょう。
WebdriverIOをインストールするたびにカスタムビルドブラウザをダウンロードする余裕がないため、Playwrightを統合する予定はありません。その開発を観察し、ある時点で統合を検討するかもしれません。
WebdriverIOチームは、今日まで唯一の真のクロスブラウザ自動化プロトコルである自動化標準として、WebDriverに引き続き投資していることを強調したいと考えています。業界全体を代表する多様なグループによって開発された標準ベースのソリューションを常に優先します。
アップデート方法
すでにWebDriverでテストを実行している場合は、何も変更する必要はありません。WebdriverIOは、実行中のブラウザドライバが見つからない場合にのみ、Puppeteerにフォールバックします。
パフォーマンスの向上
新しいリリースの大きな目標は、WebdriverIOをよりパフォーマンスが良く、より高速にすることでした。Puppeteerでテストを実行すると、ローカルでの実行をすでに高速化できます。しかし、改善するために他の分野も調べました。v6では、2020年2月11日以降完全に非推奨になったrequest
への依存を置き換えました。これにより、webdriver
およびwebdriverio
パッケージのバンドルサイズを4倍に縮小できました。
WebDriverでリクエストを行うための新しい依存関係としてgot
を使用することにより、WebdriverIOをブラウザで技術的に実行できるようになりました。これにより、興味深い可能性が生まれ、WebdriverIOスクリプト用のフィドルプラットフォームを構築するためのロードマップ項目の要件になりました。
新しいバージョンv6には、テスト実行を高速化し、CPUとメモリの使用量を削減する多くの内部改善も付属します。特に、要素のフェッチに関しては、多くのオーバーヘッドを削減し、高速化することができました。
アップデート方法
これらの改善は無料で提供され、アップグレード時にv6でパフォーマンスを向上させるために何もする必要はありません。
サービス設定
私たちは、コミュニティが作成したさまざまなサービスとレポーターの数に非常に誇りを持っています。これらの追加プラグインはすべて、wdio.conf.js
で特定の設定を必要とし、これらの設定がすべて標準化された構造になっていることを確認したいと考えています。WebdriverIO の v5 までは、サービスやレポーターに対する特定のオプションは、wdio.conf.js
内のどこにでも定義できました。たとえば、Sauce サービスなどです。
// wdio.conf.js
exports.config
// ...
services: ['sauce'],
user: process.env.SAUCE_USERNAME,
key: process.env.SAUCE_ACCESS_KEY,
region: 'us',
sauceConnect: true,
// ...
};
v6 では、すべての設定を、サービスが実際に定義されている場所に近いサービスリストに移動しました。これにより、設定ファイル内の明確な構造を維持すると同時に、さまざまな「ネイティブ」サポートされる設定のセットを明確に保つことができます。v6 では、上記の例は次のように修正する必要があります。
// wdio.conf.js
exports.config
// ...
user: process.env.SAUCE_USERNAME,
key: process.env.SAUCE_ACCESS_KEY,
region: 'us', // WebdriverIO Configuration
services: [
['sauce', {
sauceConnect: true, // @wdio/sauce-service configuration
sauceConnectOpts: { // @wdio/sauce-service configuration
// ...
}
}]
],
// ...
};
この取り組みの一環として、サービスオプション名も調べ、より短く正確な名前に変更しました。
更新方法
WDIO 設定ファイル全体を確認し、WebDriver または WDIO のオプションとして明確に定義されていない設定を探してください。これらは上記の例に従ってサービスリストに移動する必要があります。さらに、オプション名が変更されていないか確認し、必要に応じて更新してください。
コマンドインターフェースの変更
過去には、クリックのような単一のコマンドに多くの追加機能を追加し、さまざまな目的を果たしてきました。この新しい機能は、コマンドにパラメータを適用することで使用できます。残念ながら、そのようなパラメータの数が増え、多くの混乱を引き起こし、一部のコマンドが読みにくくなりました。要素がもはや存在しなくなるのを待つために $('#elem').waitForExist(null, null true)
を使用する必要があったことがあるなら、事態がどれほど悪化したか分かるでしょう。
v6 では、名前付きパラメータを許可するようにいくつかのコマンドの構造を変更しました。これにより、コードがはるかに読みやすくなり、TypeScript を使用する際の型強制が改善されます。上記の例は、v6 では次のようになります。
$('#elem').waitForExist({ reverse: true })
更新方法
次のコマンドの構造を変更しました。
-
影響を受ける
browser
メソッド -
影響を受ける要素メソッド
プロジェクトで TypeScript を使用している場合は、更新が必要なすべての場所を自動的に通知されるはずです。TypeScript を使用していない場合は、コードベース内のすべてのコマンドを検索し、それに応じて変更することをお勧めします。これは、かなり機械的で簡単な作業であるはずです。
新しいアサーションライブラリ
v6 へのアップデートにより、新しいネイティブ組み込みアサーションライブラリ expect-webdriverio
に自動的にアクセスできるようになります。これは、Jests の expect
パッケージに触発された WebdriverIO 用に特別に設計されたアサーションライブラリです。次のような主要な機能が付属しています。
- 期待が成功するのを待ちます
- 詳細なエラーメッセージ
- Mocha、Cucumber、Jest、Jasmine のサポート
- TypeScript および JS オートコンプリート用の組み込み型
これにより、WebdriverIO フレームワークのセットアップが簡素化されるだけでなく、要素の表示をチェックする場合など、アサーションが失敗した場合により優れたエラーメッセージが表示されます。
const elem = $('#someElem')
expect(elem).toHaveText('Click #2')
次のようなエラーメッセージで失敗します。
更新方法
Chai のようなアサーションライブラリを既に使用している場合は、特に expect-webdriverio
を使用することに興味がない場合は、引き続き使用できます。ただし、新しいアサーション API を使用して新しいアサーションの記述を開始し、他を削除することを決定するまで、2 つの異なるタイプのアサーションライブラリを維持することもできます。
その他の変更
上記で説明したすべての主要なアップデートに加えて、言及する価値のあるいくつかのマイナーな変更もあります。
- TypeScript のサポート: WebdriverIO と WebDriver の型定義を改善し、より詳細な説明を追加しました。
- WebDriver のデフォルトパス: ほとんどのブラウザドライバがデフォルトでこのパスを使用するようになったため、デフォルトの WebDriver パスを
/wd/hub
から/
に変更しました。これはユーザーに影響を与えないはずです。ただし、アップグレード後に WebDriver エンドポイントへの接続に問題がある場合は、これが問題の原因である可能性があります。Appium ユーザーへの注意: Appium のローカルまたはグローバルインストールを使用していて、コマンドラインから Appium を起動する場合は、CLI 引数
--base-path /
も指定する必要があります。これにより、Appium が一致するローカルエミュレータ/シミュレータ/実機を見つけられず、WebdriverIO が使用するデフォルトのpath: '/'
を使用するのを防ぐことができます。
@wdio/appium-service
を使用している場合は、何もする必要はありません。 - コマンド名の変更: Chrome WebDriver セッションの場合、コマンド
launchApp
をlaunchChromeApp
に名前を変更しました。 - スペックフィルタリング: スペックフィルタリング機能がデフォルトで有効になり、フレームワークがファイルで実行するテストを見つけることができない場合、ブラウザセッションが開始されなくなりました(これは無効にできなくなりました)。
- 新しいフック: ワーカープロセスを起動する直前に実行される
onWorkerStart
という新しいフックをテストランナーに追加しました。 - 変更されたフックシグネチャ: フレームワークのネイティブイベントオブジェクトにアクセスできるように、テスト/フックの前/後のフックのシグネチャを変更しました。設定ファイルのドキュメントを参照し、それに応じてフックを更新してください。
- Cucumber の更新:
@wdio/cucumber-framework
アダプターを Cucumber の v6 を使用するように更新しました。 - 機能の上書き: デフォルトでは、ランチャーを使用する場合、ランチャーは機能をマージするのではなく、上書きします。
LTS サポート
v6 のリリースに伴い、新しいメジャーバージョン v7 をリリースするまで、v5 のサポートを継続します。v6 から v5 にバグ修正と機能をシームレスにバックポートできるバックポートプロセスを作成しました。両方のバージョン間のコードが分岐するため、すべての機能とバグ修正をバックポートできるわけではないことに注意してください。コード貢献者には、master
ブランチに対して行われた同様の PR を v5
ブランチにも提供するように求める場合があります。
とは言え、プロジェクトに対して行われたバグ修正を確実に活用できるように、できるだけ早く最新バージョンに更新することを推奨します。