Организация набора тестов

По мере роста проектов неизбежно добавляется всё больше и больше интеграционных тестов. Это увеличивает время сборки и замедляет продуктивность.

Чтобы предотвратить это, следует запускать тесты параллельно. WebdriverIO уже тестирует каждую спецификацию (или feature file в Cucumber) параллельно в рамках одной сессии. В общем, старайтесь тестировать только одну функцию на файл спецификации. Постарайтесь не иметь слишком много или слишком мало тестов в одном файле. (Однако, здесь нет золотого правила.)

После того, как у вас появится несколько файлов спецификаций, вы должны начать запускать тесты параллельно. Для этого настройте свойство maxInstances в конфигурационном файле. WebdriverIO позволяет запускать тесты с максимальной параллельностью — это означает, что независимо от того, сколько у вас файлов и тестов, они все могут выполняться параллельно. (Это по-прежнему подчиняется определенным ограничениям, таким как CPU вашего компьютера, ограничения параллельности и т.д.)

Допустим, у вас есть 3 разных возможности (Chrome, Firefox и Safari), и вы установили maxInstances в 1. Тест-раннер WDIO создаст 3 процесса. Следовательно, если у вас 10 файлов спецификаций и вы установите maxInstances в 10, все файлы спецификаций будут тестироваться одновременно, и будет создано 30 процессов.

Вы можете определить свойство maxInstances глобально, чтобы установить атрибут для всех браузеров.

Если вы запускаете собственную сетку WebDriver, у вас может быть (например) больше мощности для одного браузера, чем для другого. В этом случае вы можете ограничить maxInstances в объекте capability:

// 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'
    }],
    // ...
}

Наследование от основного конфигурационного файла

Если вы запускаете свой набор тестов в нескольких средах (например, dev и integration), может быть полезно использовать несколько конфигурационных файлов для удобства управления.

Аналогично концепции объекта страницы, первое, что вам нужно, — это основной файл конфигурации. Он содержит все конфигурации, которые вы используете во всех средах.

Затем создайте другой файл конфигурации для каждой среды и дополните основную конфигурацию специфичными для среды:

// 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

Группировка тестовых спецификаций для последовательного запуска

Как описано выше, есть преимущества в параллельном запуске тестов. Однако, есть случаи, когда было бы полезно сгруппировать тесты для последовательного запуска в одном экземпляре. Примерами этого в основном являются случаи, когда есть большие затраты на настройку, например, транспиляция кода или подготовка облачных экземпляров, но есть также продвинутые модели использования, которые выигрывают от этой возможности.

Чтобы сгруппировать тесты для запуска в одном экземпляре, определите их как массив в определении specs.

    "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"]
  },

Это запустит файлы, соответствующие приведенному выше шаблону, в следующем порядке:

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

Запуск выбранных тестов

В некоторых случаях вы можете захотеть выполнить только один тест (или подмножество тестов) из ваших наборов.

С помощью параметра --spec вы можете указать, какой suite (Mocha, Jasmine) или feature (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 на уровне конфигурации или возможности.

Исключение выбранных тестов

При необходимости, если вам нужно исключить определенный файл спецификации (или файлы) из запуска, вы можете использовать параметр --exclude (Mocha, Jasmine) или feature (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

Исключение целого набора

Вы также можете исключить целый набор по имени. Если значение исключения соответствует имени набора, определенному в вашей конфигурации, и не выглядит как путь к файлу, весь набор будет пропущен:

wdio wdio.conf.js --suite login --suite checkout --exclude login

Это запустит только набор checkout, полностью пропустив набор login.

Смешанные исключения (наборы и шаблоны спецификаций) работают как ожидается:

wdio wdio.conf.js --suite login --exclude dialog --exclude signup

В этом примере, если signup - это определенное имя набора, этот набор будет исключен. Шаблон dialog отфильтрует любые файлы спецификаций, содержащие "dialog" в их имени файла.

примечание

Если вы указываете и --suite X, и --exclude X, исключение имеет приоритет, и набор X запущен не будет.

Когда предоставляется опция --exclude, она переопределит любые шаблоны, определенные параметром exclude на уровне конфигурации или возможности.

Запуск наборов и тестовых спецификаций

Запустите весь набор вместе с отдельными спецификациями.

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

Запуск нескольких определенных тестовых спецификаций

Иногда необходимо — в контексте непрерывной интеграции и в других случаях — указать несколько наборов спецификаций для запуска. Утилита командной строки wdio WebdriverIO принимает имена файлов, переданные через pipe (от find, grep или других).

Имена файлов, переданные через pipe, переопределяют список глобов или имен файлов, указанных в списке spec конфигурации.

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

Примечание: Это не переопределяет флаг --spec для запуска одной спецификации.

Запуск определенных тестов с MochaOpts

Вы также можете фильтровать, какие конкретные suite|describe и/или it|test вы хотите запустить, передав аргумент, специфичный для mocha: --mochaOpts.grep в CLI wdio.

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

Примечание: Mocha будет фильтровать тесты после того, как тест-раннер WDIO создаст экземпляры, поэтому вы можете увидеть, что несколько экземпляров запущены, но фактически не выполнены.

Исключение определенных тестов с MochaOpts

Вы также можете фильтровать, какие конкретные suite|describe и/или it|test вы хотите исключить, передав аргумент, специфичный для mocha: --mochaOpts.invert в CLI wdio. --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 возможности

Если задан только параметр конфигурации, он будет использоваться для всех возможностей. Однако при определении шаблона на уровне возможности он будет использоваться вместо шаблона конфигурации. Наконец, любой шаблон спецификаций, определенный в командной строке, переопределит все другие заданные шаблоны.

Использование шаблонов спецификаций, определенных на уровне возможностей

Когда вы определяете шаблон спецификаций на уровне возможности, он переопределяет любые шаблоны, определенные на уровне конфигурации. Это полезно, когда нужно разделить тесты на основе различных возможностей устройств. В таких случаях более полезно использовать общий шаблон спецификаций на уровне конфигурации и более конкретные шаблоны на уровне возможностей.

Например, предположим, у вас было два каталога, один для тестов Android и один для тестов iOS.

Ваш конфигурационный файл может определять шаблон так, для неспецифичных тестов устройств:

{
    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
        }
    ]
}