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

З ростом проектів неминуче додається все більше і більше інтеграційних тестів. Це збільшує час збірки та сповільнює продуктивність.

Щоб цьому запобігти, ви повинні запускати тести паралельно. WebdriverIO вже тестує кожну специфікацію (або feature файл у Cucumber) паралельно в межах однієї сесії. Зазвичай намагайтеся тестувати лише одну функцію на файл специфікації. Намагайтеся не мати занадто багато або занадто мало тестів в одному файлі. (Однак тут немає золотого правила.)

Коли ваші тести мають кілька файлів специфікацій, вам слід почати запускати тести одночасно. Для цього налаштуйте властивість 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'
    }],
    // ...
}

Успадкування від основного конфігураційного файлу

Якщо ви запускаєте свою тестову сюїту в декількох середовищах (наприклад, 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": [
        [
            "./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 ви можете вказати, яка сюїта (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 на рівні конфігурації або можливостей.

Виключення вибраних тестів

При необхідності, якщо вам потрібно виключити конкретний файл(и) специфікації з запуску, ви можете використовувати параметр --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 на рівні конфігурації або можливостей.

Запуск сюїт і тестових специфікацій

Запустіть цілу сюїту разом з окремими специфікаціями.

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

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

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

Імена файлів, передані через пайп, перевизначають список шаблонів або імен файлів, зазначених у списку 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
        }
    ]
}