テストスイートの構成

プロジェクトが大きくなるにつれて、必然的に統合テストが追加されます。これにより、ビルド時間が長くなり、生産性が低下します。

これを防ぐために、テストを並列に実行する必要があります。WebdriverIOは、単一のセッション内で各スペック（またはCucumberの *フィーチャーファイル*）を既に並列にテストしています。一般的に、1つのスペックファイルにつき1つの機能のみをテストするようにしてください。1つのファイルに多すぎる、または少なすぎるテストを含めないようにしてください。（ただし、ここでは黄金律はありません。）

テストに複数のスペックファイルがある場合は、テストを同時に実行する必要があります。そのためには、設定ファイルの `maxInstances` プロパティを調整します。WebdriverIOでは、テストを最大限の同時実行性で実行できます。つまり、ファイルとテストの数に関係なく、すべて並列に実行できます。（これは、コンピューターのCPU、同時実行性の制限など、特定の制限を受けます。）

3つの異なる機能（Chrome、Firefox、Safari）があり、 `maxInstances` を `1` に設定したとします。WDIOテストランナーは3つのプロセスを生成します。したがって、10個のスペックファイルがあり、 `maxInstances` を `10` に設定すると、 *すべて* のスペックファイルが同時にテストされ、30個のプロセスが生成されます。

`maxInstances` プロパティをグローバルに定義して、すべてのブラウザの属性を設定できます。

独自のWebDriverグリッドを実行している場合は、たとえば、あるブラウザの容量が別のブラウザよりも大きい場合があります。その場合、機能オブジェクトで `maxInstances` を *制限* できます。

// wdio.conf.js
export const config = {
    // ...
    // set maxInstance for all browser
    maxInstances: 10,
    // ...
    capabilities: [{
        browserName: 'firefox'
    }, {
        // maxInstances can get overwritten per capability. So if you have an in-house WebDriver
        // grid with only 5 firefox instance available you can make sure that not more than
        // 5 instance gets started at a time.
        browserName: 'chrome'
    }],
    // ...
}

メイン設定ファイルからの継承

複数の環境（例：開発と統合）でテストスイートを実行する場合、複数の構成ファイルを使用すると管理しやすくなることがあります。

ページオブジェクトの概念と同様に、最初に必要なのはメイン設定ファイルです。これには、環境間で共有するすべての構成が含まれています。

次に、環境ごとに別の設定ファイルを作成し、メイン設定を環境固有の設定で補足します。

// wdio.dev.config.js
import { deepmerge } from 'deepmerge-ts'
import wdioConf from './wdio.conf.js'

// have main config file as default but overwrite environment specific information
export const config = deepmerge(wdioConf.config, {
    capabilities: [
        // more caps defined here
        // ...
    ],

    // run tests on sauce instead locally
    user: process.env.SAUCE_USERNAME,
    key: process.env.SAUCE_ACCESS_KEY,
    services: ['sauce']
}, { clone: false })

// add an additional reporter
config.reporters.push('allure')

スイートでのテストスペックのグループ化

テストスペックをスイートにグループ化し、すべてのスイートではなく、特定のスイートのみを実行できます。

まず、WDIO設定でスイートを定義します。

// wdio.conf.js
export const config = {
    // define all tests
    specs: ['./test/specs/**/*.spec.js'],
    // ...
    // define specific suites
    suites: {
        login: [
            './test/specs/login.success.spec.js',
            './test/specs/login.failure.spec.js'
        ],
        otherFeature: [
            // ...
        ]
    },
    // ...
}

単一のスイートのみを実行する場合は、スイート名をCLI引数として渡すことができます。

wdio wdio.conf.js --suite login

または、複数のスイートを同時に実行します。

wdio wdio.conf.js --suite login --suite otherFeature

順番に実行するためのテストスペックのグループ化

上記のように、テストを同時に実行することには利点があります。ただし、テストをグループ化して単一のインスタンスで順番に実行すると便利な場合があります。このような例としては、コードのトランスパイルやクラウドインスタンスのプロビジョニングなど、セットアップコストが大きい場合が mainly に挙げられますが、この機能の恩恵を受ける高度な使用モデルもあります。

単一のインスタンスで実行するためにテストをグループ化するには、スペック定義内で配列として定義します。

    "specs": [
        [
            "./test/specs/test_login.js",
            "./test/specs/test_product_order.js",
            "./test/specs/test_checkout.js"
        ],
        "./test/specs/test_b*.js",
    ],

上記の例では、「test_login.js」、「test_product_order.js」、および「test_checkout.js」のテストは単一のインスタンスで順番に実行され、「test_b *」の各テストは個々のインスタンスで同時に実行されます。

スイートで定義されたスペックをグループ化することもできるため、次のようにスイートを定義することもできます。

    "suites": {
        end2end: [
            [
                "./test/specs/test_login.js",
                "./test/specs/test_product_order.js",
                "./test/specs/test_checkout.js"
            ]
        ],
        allb: ["./test/specs/test_b*.js"]
},

この場合、「end2end」スイートのすべてのテストは単一のインスタンスで実行されます。

パターンを使用してテストを順番に実行する場合、スペックファイルはアルファベット順に実行されます。

  "suites": {
    end2end: ["./test/specs/test_*.js"]
  },

これは、上記の patterns に一致するファイルを次の順序で実行します。

  [
      "./test/specs/test_checkout.js",
      "./test/specs/test_login.js",
      "./test/specs/test_product_order.js"
  ]

選択したテストの実行

場合によっては、スイートの単一のテスト（またはテストのサブセット）のみを実行したい場合があります。

`--spec` パラメーターを使用すると、どの *スイート*（Mocha、Jasmine）または *機能*（Cucumber）を実行するかを指定できます。パスは現在の作業ディレクトリからの相対パスで解決されます。

たとえば、ログインテストのみを実行するには

wdio wdio.conf.js --spec ./test/specs/e2e/login.js

または、複数のスペックを同時に実行します。

wdio wdio.conf.js --spec ./test/specs/signup.js --spec ./test/specs/forgot-password.js

`--spec` 値が特定のスペックファイルを指していない場合、代わりに設定で定義されたスペックファイル名をフィルタリングするために使用されます。

スペックファイル名に「dialog」という単語が含まれるすべてのスペックを実行するには、次のように使用できます。

wdio wdio.conf.js --spec dialog

各テストファイルは単一のテストランナープロセスで実行されていることに注意してください。ファイルを事前にスキャンしないため（ファイル名を `wdio` にパイプする方法については、次のセクションを参照）、スペックファイルの先頭に `describe.only` を使用して、Mochaにそのスイートのみを実行するように指示することは *できません*。

この機能は、同じ目標を達成するのに役立ちます。

`--spec` オプションが指定されている場合、設定または機能レベルの `specs` パラメーターで定義されている patterns はオーバーライドされます。

選択したテストの除外

必要に応じて、特定のスペックファイルを実行から除外する必要がある場合は、 `--exclude` パラメーター（Mocha、Jasmine）または機能（Cucumber）を使用できます。

たとえば、ログインテストを実行から除外するには

wdio wdio.conf.js --exclude ./test/specs/e2e/login.js

または、複数のスペックファイルを除外します。

wdio wdio.conf.js --exclude ./test/specs/signup.js --exclude ./test/specs/forgot-password.js

または、スイートを使用してフィルタリングする際にスペックファイルを除外します。

wdio wdio.conf.js --suite login --exclude ./test/specs/e2e/login.js

`--exclude` 値が特定のスペックファイルを指していない場合、代わりに設定で定義されたスペックファイル名をフィルタリングするために使用されます。

スペックファイル名に「dialog」という単語が含まれるすべてのスペックを除外するには、次のように使用できます。

wdio wdio.conf.js --exclude dialog

`--exclude` オプションが指定されている場合、設定または機能レベルの `exclude` パラメーターで定義されている patterns はオーバーライドされます。

スイートとテストスペックの実行

個々のスペックと共にスイート全体を実行します。

wdio wdio.conf.js --suite login --spec ./test/specs/signup.js

複数の特定のテストスペックの実行

継続的インテグレーションなどのコンテキストでは、実行する複数のスペックセットを指定する必要がある場合があります。WebdriverIOの `wdio` コマンドラインユーティリティは、パイプされたファイル名（ `find`、 `grep` などから）を受け入れます。

パイプされたファイル名は、設定の `spec` リストで指定されたglobまたはファイル名のリストをオーバーライドします。

grep -r -l --include "*.js" "myText" | wdio wdio.conf.js

***注：*** *これは、単一のスペックを実行するための `--spec` フラグを*オーバーライドしません*。

MochaOptsを使用した特定のテストの実行

wdio CLIにmocha固有の引数 `--mochaOpts.grep` を渡すことで、実行する特定の `suite | describe` または `it | test` をフィルタリングすることもできます。

wdio wdio.conf.js --mochaOpts.grep myText
wdio wdio.conf.js --mochaOpts.grep "Text with spaces"

**注：** Mochaは、WDIOテストランナーがインスタンスを作成した *後* にテストをフィルタリングするため、複数のインスタンスが生成されても実際には実行されない場合があります。

MochaOptsを使用した特定のテストの除外

wdio CLIにmocha固有の引数 `--mochaOpts.invert` を渡すことで、除外する特定の `suite | describe` または `it | test` をフィルタリングすることもできます。 `--mochaOpts.invert` は `--mochaOpts.grep` の反対を実行します。

wdio wdio.conf.js --mochaOpts.grep "string|regex" --mochaOpts.invert
wdio wdio.conf.js --spec ./test/specs/e2e/login.js --mochaOpts.grep "string|regex" --mochaOpts.invert

**注：** Mochaは、WDIOテストランナーがインスタンスを作成した *後* にテストをフィルタリングするため、複数のインスタンスが生成されても実際には実行されない場合があります。

失敗後にテストを停止する

`bail` オプションを使用すると、テストが失敗した後、テストを停止するようにWebdriverIOに指示できます。

これは、ビルドが失敗することは既にわかっているが、完全なテスト実行の長い待ち時間を避けたい場合に、大規模なテストスイートで役立ちます。

bailオプションは数値を期待し、これはWebDriverがテスト実行全体を停止する前に発生する可能性のあるテストの失敗数を指定します。デフォルトは0で、これは見つかったすべてのテスト仕様を常に実行することを意味します。

bail設定の追加情報については、オプションページを参照してください。

実行オプションの階層

どの仕様を実行するかを宣言する場合、どのパターンが優先されるかを定義する特定の階層があります。現在、これは優先順位の高いものから低いものの順に機能します。

CLI --spec 引数 > ケーパビリティ specs パターン > 設定 specs パターン CLI --exclude 引数 > 設定 exclude パターン > ケーパビリティ exclude パターン

設定パラメータのみが指定されている場合、すべてのケーパビリティに使用されます。ただし、ケーパビリティレベルでパターンを定義すると、設定パターンではなく、それが使用されます。最後に、コマンドラインで定義されたspecパターンは、指定された他のすべてのパターンをオーバーライドします。

ケーパビリティ定義のspecパターンの使用

ケーパビリティレベルでspecパターンを定義すると、設定レベルで定義されたパターンがオーバーライドされます。これは、デバイスのケーパビリティの違いに基づいてテストを分離する必要がある場合に役立ちます。このような場合、設定レベルでは汎用的なspecパターンを使用し、ケーパビリティレベルではより具体的なパターンを使用する方が便利です。

たとえば、Androidテスト用のディレクトリとiOSテスト用のディレクトリの2つのディレクトリがあるとします。

設定ファイルでは、デバイス固有でないテストのパターンを次のように定義できます。

{
    specs: ['tests/general/**/*.js']
}

しかし、AndroidデバイスとiOSデバイスには異なるケーパビリティがあり、パターンは次のようになります。

{
  "platformName": "Android",
  "specs": [
    "tests/android/**/*.js"
  ]
}

{
  "platformName": "iOS",
  "specs": [
    "tests/ios/**/*.js"
  ]
}

設定ファイルにこれらのケーパビリティの両方が必要な場合、Androidデバイスは「android」名前空間の下のテストのみを実行し、iOSテストは「ios」名前空間の下のテストのみを実行します！

//wdio.conf.js
export const config = {
    "specs": [
        "tests/general/**/*.js"
    ],
    "capabilities": [
        {
            platformName: "Android",
            specs: ["tests/android/**/*.js"],
            //...
        },
        {
            platformName: "iOS",
            specs: ["tests/ios/**/*.js"],
            //...
        },
        {
            platformName: "Chrome",
            //config level specs will be used
        }
    ]
}