UI-автоматизация тестов

Локаторы: замер выживаемости

Локатор - это способ объяснить программе, какой именно элемент на странице ей нужен. Вот результат замера, все шесть находили кнопку до редизайна: путь по структуре разметки (/html/body/div/div[2]/button[2]) - не нашёл; поиск по классу оформления .btn-primary - не нашёл, класс переименовали; поиск по порядку («вторая кнопка в блоке») - НАШЁЛ ЧУЖУЮ КНОПКУ «Назад»; поиск по точному тексту «Оплатить» - не нашёл, текст стал «Оплатить заказ»; поиск по data-testid - нашёл; поиск по роли элемента и имени - нашёл.

Самый плохой исход тут не красный тест, а третий случай. Тест остался зелёным и продолжил нажимать не ту кнопку - то есть проверка молча перестала проверять то, ради чего написана. Красный тест ты чинишь за час, а такой можно не заметить месяцами.

// Отсюда порядок предпочтений. Первым - data-testid: специальный атрибут, который фронтенд ставит на важные элементы именно для тестов, и который не трогают при перекраске. Вторым - роль элемента с его подписью (кнопка с именем «Оплатить»). Роль - это чем элемент считается для браузера и для программ чтения с экрана: кнопка, ссылка, поле ввода, заголовок. Она есть у любого осмысленного элемента и переживает перестановку блоков. Дальше - обычные селекторы по стабильным признакам. И в самом конце - путь по структуре разметки, который умирает от первого же изменения.

локатор

способ указать программе конкретный элемент на странице

data-testid

атрибут, который фронтенд ставит специально для тестов; договор, а не оформление

Ожидания: замер трёх стратегий

Второй источник нестабильности - время. Я сделал страницу, где кнопка появляется через 0,8 секунды после загрузки, и попробовал три подхода. «Подожду 3 секунды, наверняка хватит»: 3080 миллисекунд, клик прошёл. «Подожду полсекунды, должно хватить»: упал - элемента ещё нет. Клик с ожиданием самого элемента, без фиксированной паузы: 1317 миллисекунд, клик прошёл.

Первый вариант работает, но платит полную цену всегда: на двухстах тестах эти лишние секунды складываются в минуты простоя. Второй - лотерея: на быстрой машине пройдёт, на загруженном сервере сборки упадёт. Третий возвращается сразу, как только элемент готов, и держит запас времени на случай задержки. Это и есть явное ожидание: ждём условие (элемент видим, кнопка активна, запрос завершился), а не отрезок времени.

// Приятный побочный эффект - падение становится читаемым. Когда я нажал на выключенную кнопку, инструмент подождал полторы секунды и написал прямо: ждал элемент, элемент нашёлся как <button disabled>, пытался кликнуть, ожидал, что он станет видимым, активным и перестанет двигаться. Со sleep на этом месте была бы просто ошибка «клик не удался».

# лотерея: угадываем время
time.sleep(3)
page.click("#pay")

# ожидание условия: вернётся сразу,
# как только кнопка станет активной
page.get_by_test_id("pay").click()

явное ожидание

ждём условие с запасом по времени, а не фиксированную паузу

цена ожидания

лишние 3 секунды на шаг превращаются в минуты на наборе

Короткий путь и следы падения

Правило, которое экономит больше всего: через интерфейс проверяем только то, что проверяем, всё остальное готовим в обход. Вход в аккаунт - подстановкой готового токена (строки-пропуска, которую сервер выдаёт после успешного входа), а не заполнением формы. Товары в корзине, заказы, промокоды - прямыми вызовами к серверу. Если каждый из двухсот тестов честно логинится через форму по 40 секунд, это два с лишним часа на прогон и двести дополнительных мест, где можно поймать нестабильность.

Изоляция обязательна: свои данные и свой пользователь на каждый тест, независимость от порядка. Тест, которому нужен след предыдущего, ломается, как только кто-то поменяет порядок или запустит набор в несколько потоков.

// И про следы падения. Прогон на сервере сборки - на машине, которая сама гоняет тесты после каждого изменения, - отличается от локального: браузер работает без окна, ресурсов меньше, скорость сети другая, таймзона тоже. Поэтому при падении собирают скриншот, видео, запись действий и логи сети. Без них фраза «упало на сервере, локально всё хорошо» превращается в вечную загадку.

подготовка мимо интерфейса

вход и данные ставятся вызовами к серверу, а не кликами

артефакты падения

скриншот, видео, запись действий и логи - собираются при каждом провале

Как отвечать: «Почему sleep - зло и как ждать правильно?»

Потому что это ставка на фиксированное время в системе, где время плавает. Я мерил три подхода на странице, где кнопка появляется через восемь десятых секунды. Пауза в три секунды - работает, но каждый шаг стоит три секунды, а на двухстах тестах это минуты чистого простоя. Пауза в полсекунды - тест упал, элемента ещё нет; на другой машине он бы прошёл, и получилась бы мигалка. А клик с ожиданием самого элемента занял чуть больше секунды и прошёл: он возвращается сразу, как только условие выполнено, и держит запас времени на случай тормозов. То есть фиксированная пауза одновременно и медленная, и ненадёжная, а ожидание условия быстрее и стабильнее. Ждать нужно события: элемент стал видимым и активным, запрос завершился, индикатор загрузки исчез. Есть и приятный побочный эффект - когда я ждал условие и оно не выполнилось, инструмент написал причину прямым текстом: элемент найден, но он выключен. С паузой на этом месте было бы безликое «клик не удался». Фиксированную паузу оставляю только как временный костыль при отладке.

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

На чём валят

• −Локатор по структуре разметки или по классу оформления - из шести способов редизайн пережили два.
• −Локатор «вторая кнопка в блоке»: тест остаётся зелёным и жмёт «Назад» вместо «Оплатить».
• −Фиксированная пауза вместо ожидания: 3 секунды на шаг или падение на загруженном сервере.
• −Каждый тест логинится через форму - 40 секунд на двести тестов это два часа прогона.
• −Не собирать скриншоты и записи при падении - «на сервере упало, локально ок» не разобрать.