Оптимизация UI-тестов с помощью API. Как избавиться от боли и ускорить автотесты в разы

Привет всем! Я главный специалист по автоматизации тестирования в компании ITFB Group. Знакомо, когда UI-тесты работают медленно, падают из-за ерунды и отнимают кучу времени? Мы нашли решение - грамотно комбинируем API и UI проверки. Теперь тесты летают! Хотите так же? Сейчас расскажу, как это сделать.

Если вы когда-либо писали UI-автотесты, вы точно знаете это чувство: тесты работают медленно, падают без очевидной причины, и чем больше их становится, тем сложнее их поддерживать. На первый взгляд всё логично — мы тестируем глазами пользователя. Но стоит копнуть чуть глубже — и окажется, что большая часть времени уходит вовсе не на проверки, а на рутину: авторизацию, заполнение одних и тех же форм, ожидание загрузки элементов. Так может, пора перестать делать лишнюю работу?

В этой статье разберёмся, как API могут значительно ускорить ваши автотесты для тестирования фронта.

Что не так с UI‑тестами?

Начнём с базового. Классический UI-тест — это имитация действий пользователя в браузере. Вводим логин, пароль, нажимаем кнопку, ждём загрузку страницы, кликаем по меню, заполняем форму, отправляем, проверяем результат. Красиво. Информативно. И невыносимо медленно.

Типичный проблемный набор:

Скорость: браузеру нужно отрисовать DOM, загрузить скрипты, дождаться анимаций, и только потом тест сможет кликнуть. Один вход в систему легко занимает 30+ секунд.
Хрупкость: один лишний div, новая обёртка или анимированная загрузка — и тест падает.
Поддержка: если у вас хотя бы 500–1000 тестов, то без рефакторинга жить невозможно. А рефакторинг UI-тестов — удовольствие сомнительное.
Цена: даже если CI гоняет тесты параллельно, общее время прогона в часах — это обычная история. Плюс вы тратите время на отладку, локализацию проблем и переписывание логики после любого обновления фронта.

При этом все понимают, зачем нужны UI-тесты — это единственный способ убедиться, что система работает с точки зрения пользователя. Именно поэтому вы не можете просто взять и отказаться от E2E-тестов. Но вы можете их улучшить.

API в помощь: гибридный подход

Вместо того чтобы пытаться тестировать всё через UI, давайте делегировать.

UI оставим для того, чтобы проверить:
- что элемент виден/не виден;
- что текст ошибки отображается;
- что пользователь может реально кликнуть и получить результат.

А всё остальное — авторизация, генерация данных, подготовка состояния, валидация логики — отдаём API.

Авторизация через API

Один из самых медлительных шагов во всех UI-тестах — логин. И именно его можно выкинуть из браузера без последствий.

До

Открыть login.html → ввести логин → ввести пароль → нажать кнопку → подождать → проверить, что мы на dashboard.

После

# Получаем токен через API
response = requests.post(API_AUTH_URL, json={"login": "test", "password": "123"})
token = response.json()["token"]

# Кладём токен в cookie браузера
driver.add_cookie({"name": "session_id", "value": token})
driver.refresh()  # Всё, мы авторизованы

Теперь каждый тест стартует уже из "внутреннего" состояния, без лишней прелюдии. Время входа падает с 30–40 секунд до 5–7. Плюс вы не зависите от того, как в этот раз работает капча, не сломался ли редирект, и не добавили ли на страницу новый баннер с анимацией, которая ломает фокус ввода.

Валидация через API

Другой кандидат на "вынесение" — логика валидации. Часто в тестах нужно проверить, как форма реагирует на валидные и невалидные данные. Но вы же не обязаны гонять 20 разных email'ов через UI, чтобы получить ответ сервера.

Вместо

Открыть форму → ввести email → нажать submit → ждать появления ошибки → проверять текст.

Делаем

response = requests.post(API_VALIDATE_URL, json={"email": "wrong@wrong"})
assert response.status_code == 400

Тут же можно отсечь 20 проблемных кейсов за 2 секунды, а не за минуту. А в UI оставить один тест на happy path и пару тестов на отображение ошибок — проверить, что "Введите корректный email" действительно появляется.

Подготовка данных без UI

Нужны пользователи, заказы, продукты? Не создавайте их руками в UI. Это мучительно медленно и ненадёжно. Делайте это либо напрямую через API, либо через тестовые хелперы, либо вообще через фикстуры/дампы БД.

Параллелим всё, что можно

Раз уж тесты стали быстрыми — не мешает их ещё и запараллелить. Selenium Grid / Selenoid, Moon — инструментов куча. Главное — не забывать про чистку данных и изоляцию сессий. При правильной конфигурации вы можете гнать 100 тестов за 3–5 минут, а не за час.

Когда API недостаточно

Важно понимать: API не заменит всё. Вы не увидите, как рендерится компонент. Не заметите, что кнопка визуально перекрыта или имеет некорректный стиль. И не отловите баг, когда при нажатии на "Удалить" появляется пустой модал. Все элементы фронта всё равно удастся проверить только в браузере.

Заключение

Гибридные автотесты — это не просто технический трюк. Это философия: меньше тестировать "как пользователь", больше тестировать "как система". Использование API на этапах подготовки, авторизации и валидации — это не костыль, а способ превратить UI-тесты из тормозного болота в быстрый и понятный инструмент.

Если вам кажется, что ваши UI-тесты невыносимы — скорее всего, вы тестируете через UI слишком много. Попробуйте вынести авторизацию и валидацию через API. Скорее всего, вы удивитесь, насколько всё становится быстрее и стабильнее. А потом уже не захотите возвращаться назад.

Инструменты, которые пригодятся:

Playwright / Selenium — для UI-тестов;
Selenium Grid/Selenoid или Moon — если хочется параллельных тестов;
Библиотека requests — для API-запросов на Python;
pytest — обязателен для работы с любыми автотестами на Python.