Комментарии 11
Очень подробно, спасибо!
Кстати, у Test IT видела, что недавно был анонс бесплатного тарифа.
При импорте библиотеки можешь делать следующим образом:import requests as r
Таким образом, будет короче вызвать метод
response = r.get(url=url, headers=headers, params=params)
Конечно, можно сокращать код, но важно, чтобы он оставался читабельным и поддерживаемым в дальнейшем.
Понял) При assert на статус-код советую выводить следующее выражение в конце проверки, чтобы получать конкретную ошибку:
assert response.status_code == 200, f'Ожидался статус-код 200 ОК, но получен {response.status_code}'
Также можно сократить, необязательно их уточнять:
response = requests.get(url, headers, params)
Ps: в качестве проверки на тело ответа можно валидировать схемы
Справедливо, это поможет быстрее понять, в чем ошибка.
Пример, который я привожу, я даю в максимально полном формате, чтобы он был понятен всем. А так да, можно сократить.
Проверять схемы нужно, но не всегда это приоритет. Как по мне, важнее сначала покрыть функционал реальными пользовательскими кейсами.
P.S. Улучшать ваши автотесты можно до бесконечности, важно держать в голове, действительно ли эти "улучшения" принесут максимум пользы или лучше заняться другим направлением.
А еще можно добавть --showlocals к запуску пайтеста, и не париться с сообщениями.
Ну и прекращаем использовать магические константы. Тем более что их уже за вас определили. https://docs.python.org/3/library/http.html#http.HTTPStatus
Вы в реальных тестах действительно используете requests.get
? Или для простоты добавили?
Обычно когда запросов много, хочется переиспользовать клиента, так как установка соеденения это дорого. https://requests.readthedocs.io/en/latest/user/advanced/#session-objects
Спасибо за подробную статью
Автотесты: от первого автотеста до масштабного проекта. Мой набор инструментов для масштабирования