API-тесты тоже флейкают 😭
В автоматизации есть иерархия стабильности. Считается, что UI-тесты (веб и мобилки) - это всегда зона риска, а API-тесты - это идеал стойкости: быстрые, надежные и стабильные. 🏔
Так - в теории, а на практике API-тесты часто бывают капризными. Когда они начинают флейкать (то падать, то проходить без правок кода), это раздражает даже больше, чем упавший Selenium. От бэкенда мы ждем непредсказуемости в последнюю очередь.
Почему API-тест перестает быть надежным? 📉
Если кажется, что API-автоматизация - это просто assert response.status_code == 200, то в реальности, она посложнее. Вот что вас ждет:
➖Гонка со сторонними сервисами 🏃♂️: Ваш тест дергает эндпоинт, который идет в сторонний платежный шлюз или сервис рассылок. Сторонний сервис задержался на пару секунд - и ваш тест падает по таймауту.
➖Консистентность данных ⏱️: Вы создаете юзера в одном микросервисе, а проверить его пытаетесь в другом. Данные еще не успели синхронизироваться в БД или Elastic, и ваш ассерт смотрит на пустой ответ.
➖Загрязнение окружения 🧹: Тест А создал данные и не удалил их. Теперь тест Б падает, потому что "такой email уже существует". В итоге у вас не изоляция, а "коммунальная квартира" с общими зависимостями.
➖Хрупкие тестовые данные: Кто-то вручную изменил конфиг в БД или удалил того самого юзера, на котором держалось пол-пайплайна. 🤯
Как лечить нестабильность? 🛠
Игнорировать флейки нельзя - они подрывают доверие ко всей автоматизации. Если отчеты краснеют без причины, пора внедрять правильные паттерны. И с хрупкими данными понятно - используй стабильные, выверенные. Всегда чисти после теста - официально - "возвращай систему в то же состояние, которое было до теста". Но что делать с задержками синхронизации, лагами. Ведь time.sleep() - это фу-фу-фу
В Python один из лучших помощников - библиотека tenacity. Она позволяет настроить умные ретраи (повторные попытки). Вместо того чтобы падать сразу, тест подождет и попробует еще раз, это часто решает проблемы с долгой синхронизацией.
Что стоит внедрить:
➖tenacity.retry - для повторов с задержкой ⏳
➖Умные ожидания - вместо time.sleep() используем циклы с проверкой условия, пока данные не появятся в базе или где вы их там ждете
➖Pytest-rerunfailures - это на крайняк для перезапуска упавшего теста целиком, если вылечить сложно, а перепрогон в большинстве случаев помогает
Вот простенький пример, чтобы можно было сразу попробовать. Страница https://analytics-api.com/users/42 вернет 404 и степ повторится 3 раза - увидите это по повторяющемуся "Валидирую статус ответа"
import requests
from tenacity import retry, stop_after_attempt, wait_fixed
# Пробуем 3 раза с паузой в 2 секунды
@retry(stop=stop_after_attempt(3), wait=wait_fixed(2))
def step_wait_for_data(user_id):
response = requests.get(f"https://analytics-api.com/users/{user_id}")
# Если статус не 200, ассерт падает, вызывая AssertionError.
# Tenacity ловит это исключение и запускает повтор.
print("Валидирую статус ответа")
assert response.status_code == 200
return response.json()
def test_data():
# Тест будет идти до 6 секунд, если данные появятся не сразу
user_data = step_wait_for_data(42)
assert user_data['name'] == "Ivan"
Но! Осторожно с ретраями, а тем более реранами. ⚠️
В приложении может реально быть проблема. Например, эндпоинт отрабатывает всегда только с третьего раза. Сначала разберитесь с проблемой, сходите с ней к разработчикам или другим ответственным. И только если вам сказали (или вы знаете из опыта), что такое поведение почему-то ок, то retry - то, что вам надо
Стабильность - это не удача, а результат выбора правильных инструментов и архитектуры. 👨💻
Если вы всё еще лечите флейки через time.sleep(5), моргните два раза в комментариях 👇
Мы вас не осудим (почти)
