メインコンテンツにスキップ

不安定なテストの再実行

WebdriverIOテストランナーを使用すると、ネットワークの不安定さや競合状態などによって不安定になった特定のテストを再実行できます。（ただし、テストが不安定になった場合に単に再実行回数を増やすことはお勧めしません！）

Mochaでスイートを再実行する​

Mochaバージョン3以降では、テストスイート全体（`describe`ブロック内のすべて）を再実行できます。Mochaを使用する場合は、特定のテストブロック（`it`ブロック内のすべて）のみを再実行できるWebdriverIOの実装ではなく、この再試行メカニズムを優先する必要があります。Mochaのドキュメントに記載されているように、 `this.retries()`メソッドを使用するには、スイートブロック`describe`でファットアロー関数`() => {}`ではなく、非バインド関数`function(){}`を使用する必要があります。Mochaを使用すると、`wdio.conf.js`で`mochaOpts.retries`を使用して、すべてのスペックの再試行回数を設定することもできます。

例を以下に示します。

describe('retries', function () {
    // Retry all tests in this suite up to 4 times
    this.retries(4)

    beforeEach(async () => {
        await browser.url('http://www.yahoo.com')
    })

    it('should succeed on the 3rd try', async function () {
        // Specify this test to only retry up to 2 times
        this.retries(2)
        console.log('run')
        await expect($('.foo')).toBeDisplayed()
    })
})

JasmineまたはMochaで単一のテストを再実行する​

特定のテストブロックを再実行するには、テストブロック関数の最後のパラメータとして再実行回数を適用するだけです。

describe('my flaky app', () => {
    /**
     * spec that runs max 4 times (1 actual run + 3 reruns)
     */
    it('should rerun a test at least 3 times', async function () {
        console.log(this.wdioRetries) // returns number of retries
        // ...
    }, 3)
})

フックにも同じことが適用されます。

describe('my flaky app', () => {
    /**
     * hook that runs max 2 times (1 actual run + 1 rerun)
     */
    beforeEach(async () => {
        // ...
    }, 1)

    // ...
})

この再試行メカニズムでは、単一のフックまたはテストブロックのみを再試行できます。テストにアプリケーションをセットアップするためのフックが付属している場合、このフックは実行されません。Mochaはこの動作を提供するネイティブテストの再試行を提供しますが、Jasmineは提供しません。実行された再試行回数には、`afterTest`フックでアクセスできます。

Cucumberでの再実行​

Cucumberでスイート全体を再実行する​

cucumber >=6の場合、`retry`設定オプションとオプションの`retryTagFilter`パラメータを指定して、失敗したシナリオのすべてまたは一部が成功するまで追加の再試行を取得できます。この機能を動作させるには、`scenarioLevelReporter`を`true`に設定する必要があります。

Cucumberでステップ定義を再実行する​

特定のステップ定義の再実行回数を定義するには、次のように再試行オプションを適用するだけです。

export default function () {
    /**
     * step definition that runs max 3 times (1 actual run + 2 reruns)
     */
    this.Given(/^some step definition$/, { wrapperOptions: { retry: 2 } }, async () => {
        // ...
    })
    // ...
})

再実行はステップ定義ファイルでのみ定義でき、機能ファイルでは定義できません。

スペックファイルごとに再試行を追加する​

以前は、テストレベルとスイートレベルの再試行のみが利用可能でした。これはほとんどの場合問題ありません。

ただし、状態（サーバー上またはデータベース内など）を含むテストでは、最初のテストの失敗後に状態が無効のままになる可能性があります。後続の再試行は、開始時の無効な状態が原因で、成功する可能性がありません。

スペックファイルごとに新しい`browser`インスタンスが作成されるため、これは他の状態（サーバー、データベース）をフックしてセットアップするのに最適な場所です。このレベルでの再試行は、セットアッププロセス全体が新しいスペックファイルの場合と同様に、単に繰り返されることを意味します。

wdio.conf.js
export const config = {
    // ...
    /**
     * The number of times to retry the entire specfile when it fails as a whole
     */
    specFileRetries: 1,
    /**
     * Delay in seconds between the spec file retry attempts
     */
    specFileRetriesDelay: 0,
    /**
     * Retried specfiles are inserted at the beginning of the queue and retried immediately
     */
    specFileRetriesDeferred: false
}

特定のテストを複数回実行する​

これは、コードベースに不安定なテストが導入されるのを防ぐのに役立ちます。 `--repeat` CLIオプションを追加すると、指定されたスペックまたはスイートがN回実行されます。このCLIフラグを使用する場合は、`--spec`または`--suite`フラグも指定する必要があります。

コードベースに新しいテストを追加する場合、特にCI / CDプロセスを介して、テストは合格してマージされる可能性がありますが、後で不安定になる可能性があります。この不安定さは、ネットワークの問題、サーバーの負荷、データベースのサイズなど、さまざまな原因が考えられます。CD / CDプロセスで`--repeat`フラグを使用すると、これらの不安定なテストがメインのコードベースにマージされる前にキャッチできます。

使用する1つの戦略は、CI / CDプロセスで通常どおりテストを実行することですが、新しいテストを導入する場合は、`--spec`で指定された新しいスペックと`--repeat`を指定して別のテストセットを実行し、新しいテストをx回実行します。テストがこれらのいずれかの時間に失敗した場合、テストはマージされず、失敗した理由を調べる必要があります。

# This will run the example.e2e.js spec 5 times
npx wdio run ./wdio.conf.js --spec example.e2e.js --repeat 5

ようこそ！何かお困りですか？

WebdriverIO AI Copilot