Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Таймауты — одна из ключевых частей end-to-end тестирования UI. При тестировании пользовательских интерфейсов мы часто сталкиваемся с различными формами случайности (или кажущейся случайности) в том, как элементы появляются и взаимодействуют.

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

Таймауты vs жёсткие ожидания

Чем таймауты отличаются от жёстких ожиданий? Жёсткие ожидания полностью останавливают выполнение теста. При использовании жёсткого ожидания мы фактически отключаемся от тестируемого приложения, надеясь, что за это время приложение достигнет нужного состояния. Такой подход по своей природе ненадёжен, потому что он оторван от того, что реально делает приложение.

// Не используйте жёсткие ожидания
const button = $('aria/Submit')
   // ❌ Останавливает выполнение на 2 секунды, независимо от состояния
browser.pause(2000)
await expect(button).toBeDisplayed() 

Таймауты, с другой стороны, позволяют оставаться «на связи» с тестируемым приложением. Они дают возможность постоянно проверять состояние приложения и обычно работают быстрее — мы переходим к следующей команде, как только условие выполнено.

// Намного лучше
const button = $('aria/Submit')
// ✅ Продолжать, как только элемент найден
await expect(button).toBeDisplayed()

Типы таймаутов в WebdriverIO

Рассмотрим таймауты на реальном примере. У меня есть небольшое игровое приложение с тремя закрытыми дверями, за которыми скрываются разные персонажи — некоторые из них враждебны, а некоторых нужно защищать.

При каждом запуске игры время появления персонажа случайно, что создаёт проблему для теста.

Вот базовый тест, который учитывает эту случайность:

import { browser, $ } from '@wdio/globals'
it('open all three doors (waitForDisplayed)', async () => {
   await browser.url('/')
 
   const startGameButton = $('[data-test="start-game-button"]')
 
   // Start the game
   await startGameButton.waitForDisplayed()
   await startGameButton.click()
 
   const door1 = $('aria/Door 1')
   const door2 = $('aria/Door 2')
   const door3 = $('aria/Door 3')
 
   await door1.waitForDisplayed()
   await door2.waitForDisplayed()
   await door3.waitForDisplayed()
})

Этот тест проходит даже при случайном времени появления элементов, потому что команда waitForDisplayed повторяет попытки, пока не найдёт элемент. Но сколько времени она ждёт?

Ответ кроется в конфигурации WebdriverIO:

wdio.conf.ts
export const config: Options.Testrunner = {
   // ... существующий код ...
   waitforTimeout: 10000, // Таймаут по умолчанию для всех команд waitFor
   // ... существующий код ...
   mochaOpts: {
      ui: 'bdd',
      timeout: 30000 // Общий таймаут теста
   },
}

Параметр waitforTimeout определяет, как долго мы хотим ждать выполнения всех команд waitFor (например, waitForDisplayed, waitForClickable, waitForEnabled и др.). Если бы мы установили этот таймаут на 1 секунду, тест, скорее всего, не прошёл бы, потому что элементы часто появляются дольше.

Также можно задавать таймауты для отдельных команд:

await door3.waitForDisplayed({ timeout: 1000 }) // Таймаут только для этой команды

Таймауты для набора тестов

Ещё один важный таймаут определяет продолжительность всего теста. В нашем примере тест выполняется примерно 12 секунд. Для более длинных тестов мы можем задать верхний предел с помощью опции timeout в Mocha.

Таймаут по умолчанию в Mocha — 30 секунд, но его можно изменить в конфигурации:

mochaOpts: {
   ui: 'bdd',
   timeout: 30000 // Измените это значение, чтобы задать таймаут теста
}

Лучшие практики

Таймауты — отличный способ задать верхние пределы для действий в тестах, но нужно быть осторожным и не устанавливать их слишком высоко. Помните, что таймаут также определяет, через какое время ваш тест завершится с ошибкой. Если у вас в наборе несколько тестов, которые могут упасть, слишком большие таймауты значительно увеличат общее время выполнения.

Обсудить в форуме