デバッグ
複数のプロセスが複数のブラウザで数十ものテストを生成する場合、デバッグははるかに困難になります。
まず、maxInstances
を1
に設定し、デバッグする必要があるスペックとブラウザのみを対象とすることで、並列処理を制限することが非常に役立ちます。
wdio.conf
内
export const config = {
// ...
maxInstances: 1,
specs: [
'**/myspec.spec.js'
],
capabilities: [{
browserName: 'firefox'
}],
// ...
}
デバッグコマンド
多くの場合、browser.debug()
を使用してテストを一時停止し、ブラウザを検査できます。
コマンドラインインターフェースもREPLモードに切り替わります。このモードでは、ページ上のコマンドと要素を操作できます。REPLモードでは、テストと同様にbrowser
オブジェクト、または$
および$$
関数にアクセスできます。
browser.debug()
を使用する場合、テストの実行時間が長すぎるためにテストランナーがテストに失敗することを防ぐために、テストランナーのタイムアウトを増やす必要があるでしょう。例えば
wdio.conf
内
jasmineOpts: {
defaultTimeoutInterval: (24 * 60 * 60 * 1000)
}
他のフレームワークを使用した方法の詳細については、タイムアウトを参照してください。
デバッグ後にテストを続行するには、シェルで^C
ショートカットまたは.exit
コマンドを使用します。
動的設定
wdio.conf.js
にはJavaScriptを含めることができます。タイムアウト値を1日に永久に変更したくない場合は、環境変数を使用してコマンドラインからこれらの設定を変更することが役立つ場合があります。
このテクニックを使用して、設定を動的に変更できます。
const debug = process.env.DEBUG
const defaultCapabilities = ...
const defaultTimeoutInterval = ...
const defaultSpecs = ...
export const config = {
// ...
maxInstances: debug ? 1 : 100,
capabilities: debug ? [{ browserName: 'chrome' }] : defaultCapabilities,
execArgv: debug ? ['--inspect'] : [],
jasmineOpts: {
defaultTimeoutInterval: debug ? (24 * 60 * 60 * 1000) : defaultTimeoutInterval
}
// ...
}
次に、wdio
コマンドにdebug
フラグを接頭辞として付けることができます。
$ DEBUG=true npx wdio wdio.conf.js --spec ./tests/e2e/myspec.test.js
…そして、DevToolsでスペックファイルをデバッグします!
Visual Studio Code (VSCode)を使用したデバッグ
最新のVSCodeでブレークポイントを使用してテストをデバッグする場合は、デバッガを起動するための2つのオプションがあります。オプション1は最も簡単な方法です。
- デバッガの自動アタッチ
- 設定ファイルを使用したデバッガのアタッチ
VSCode自動アタッチの切り替え
VSCodeで次の手順に従って、デバッガを自動的にアタッチできます。
- CMD + Shift + P(LinuxおよびmacOS)またはCTRL + Shift + P(Windows)を押します。
- 入力フィールドに「attach」と入力します。
- 「Debug: Toggle Auto Attach」を選択します。
- 「Only With Flag」を選択します。
これで完了です!テストを実行すると(前述のように設定で--inspectフラグを設定する必要があることを覚えておいてください)、デバッガが自動的に起動し、到達した最初のブレークポイントで停止します。
VSCode設定ファイル
すべてのスペックファイルまたは選択したスペックファイルを実行できます。選択したスペックをデバッグするには、デバッグ設定を.vscode/launch.json
に追加する必要があります。次の設定を追加します。
{
"name": "run select spec",
"type": "node",
"request": "launch",
"args": ["wdio.conf.js", "--spec", "${file}"],
"cwd": "${workspaceFolder}",
"autoAttachChildProcesses": true,
"program": "${workspaceRoot}/node_modules/@wdio/cli/bin/wdio.js",
"console": "integratedTerminal",
"skipFiles": [
"${workspaceFolder}/node_modules/**/*.js",
"${workspaceFolder}/lib/**/*.js",
"<node_internals>/**/*.js"
]
},
すべてのスペックファイルを実行するには、"args"
から"--spec", "${file}"
を削除します。
追加情報: https://vscode.dokyumento.jp/docs/nodejs/nodejs-debugging
Atomを使用した動的REPL
Atomユーザーの方は、wdio-repl
(@kurtharriger作成)を試すことができます。これは、Atomで単一行のコードを実行できる動的REPLです。このYouTubeビデオでデモをご覧ください。
WebStorm / Intellijを使用したデバッグ
次のようなnode.jsデバッグ設定を作成できます。 設定方法の詳細については、このYouTubeビデオをご覧ください。
不安定なテストのデバッグ
不安定なテストはデバッグが非常に困難なため、CIで発生した不安定な結果をローカルで再現する方法について、いくつかのヒントを紹介します。
ネットワーク
ネットワーク関連の不安定性をデバッグするには、throttleNetworkコマンドを使用します。
await browser.throttleNetwork('Regular3G')
レンダリング速度
デバイス速度関連の不安定性をデバッグするには、throttleCPUコマンドを使用します。これにより、ページのレンダリング速度が低下します。これは、CIで複数のプロセスを実行することでテストが遅くなるなど、多くの原因によって発生する可能性があります。
await browser.throttleCPU(4)
テスト実行速度
テストに影響がないように見える場合、WebdriverIOがフロントエンドフレームワーク/ブラウザからの更新よりも高速である可能性があります。これは、同期アサーションを使用する場合に発生します。WebdriverIOには、これらのアサーションを再試行する機会がなくなります。このため、破損する可能性のあるコードの例を以下に示します。
expect(elementList.length).toEqual(7) // list might not be populated at the time of the assertion
expect(await elem.getText()).toEqual('this button was clicked 3 times') // text might not be updated yet at the time of assertion resulting in an error ("this button was clicked 2 times" does not match the expected "this button was clicked 3 times")
expect(await elem.isDisplayed()).toBe(true) // might not be displayed yet
この問題を解決するには、代わりに非同期アサーションを使用する必要があります。上記の例は次のようになります。
await expect(elementList).toBeElementsArrayOfSize(7)
await expect(elem).toHaveText('this button was clicked 3 times')
await expect(elem).toBeDisplayed()
これらのアサーションを使用すると、WebdriverIOは条件が一致するまで自動的に待機します。テキストをアサートする場合、これは要素が存在し、テキストが期待値と等しい必要があることを意味します。これについては、ベストプラクティスガイドで詳しく説明しています。