unsstrennen Jul 20 2020 at 13:33

API для генерации ответов сервера с любыми кодами статусов

2 min

8.2K

API*Web services testing*

Comments 19

Denai Jul 20 2020 at 13:49

http://httpme.tk/418 отрабатывает. Так и запишем

trolley813 Jul 20 2020 at 13:50

Интересно, работает ли с нестандартными кодами статусов (601, 999 и так далее)? Пробовал с мобильного браузера зайти, она как будто бы отдает 500 Internal Server Error на такое.

unsstrennen Jul 20 2020 at 14:18

API разрабатывалось с опорой на стандартные коды HTTP. Но это поправимо. Если вы пишете этот комментарий, значит, вероятно, обработка нестандартных кодов статусов тоже должна быть предусмотрена, так? Это поправимо, но есть ли смысл?...

TheGodfather Jul 20 2020 at 14:05

Мне кажется, или вы изобрели велосипед, аналогичный пресловутому MagicMock? Если вы тестируете black-box обработчик API, то у него должна быть инверсия зависимостей, банально что-нибудь вроде api = MyApi(url='http://prod-server.com'). Если так, то ни мокнуть ответы не получится (точнее, получится, если мокать низкоуровневый request, но это уже детали реализации, которые не хотелось бы тестировать), ни ваш подход не подойдет (потому что апишка не будет звать ваштестсервер.ру/500, она будет звать адреса эндпоинтов).

Но если диалог с разработчиками был построен, то, быть может, реализована еще одна ступень декомпозиции: backend = BackendServer(url='http://prod-server.com'); api = MyApi(backend=backend ), и тут уже все просто — чтобы простестить API, достаточно мокнуть целиком backend с известным интерфейсом, и уже смотреть на то, как обработчик MyAPI себя будет вести, когда ваш мокнутый бекенд будет возвращать ерунду.

kalombo Jul 20 2020 at 14:27

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

unsstrennen Jul 20 2020 at 14:35

То, что вы считаете поводом для критки — является плюсами)

Поднимать локальный сервис или искусственно моделировать запросы используя функционал своего фреймворка — можно, эффект такой же. А что, если нужно проверить именно "не у себя" и именно через интернет? Если вы тестируете обёртку внешнего API, я бы пользовался внешними сервисами для тестов.

Логика "избегать внешних сервисов дабы не упали тесты" объективна, но… А почему вы cloudflare используете? вот у него сервера упали и всё легло? а php? вдруг в сборке баг и всё ляжет?)

kalombo Jul 20 2020 at 14:41

Ну тогда, во-первых, лучше поднять свой сервис на хостинге, а не зависеть от httpme.tk который вы можете вырубить когда захотите или он может тупо лечь, если все начнут им пользоваться.

А что, если нужно проверить именно «не у себя» и именно через интернет?

Поясните, пожалуйста, чем сервис локальный будет отличаться от сервиса в интернете? Что вы хотите проверить?

unsstrennen Jul 20 2020 at 14:45

С функциональной точки зрения — ничем. Хостинг у меня свой, я его стерегу как зеницу ока ибо там и мои проекты, в т.ч. не мои, за размещение которых я плачу.

С функциональной точки зрения локальный сервис не будет отличаться ничем. На основе ваших комментариев, у меня появилась идея, и я хотел бы, чтобы вы оценили её полезность. Можно добавить возможность быстрого развёртывания моего веб-приложения как локальный сервис. Чтобы в случае необходимости тестирования blackbox API разработчик мог быстро установить и поднять мой сервис во внутренней корпоративной сети, например? или просто на localhost.

kalombo Jul 20 2020 at 14:53

Вы можете создать plugin для для pytest — fixture в которой будет код вашего flask-приложения. Правда погуглив нашел, что что-то подобное уже есть github.com/csernazs/pytest-httpserver

Jho00 Jul 20 2020 at 14:41

Часто бывает нужно обработать не только определенный ошибочный статус — код, но еще и сам ответ от сервера. Например, из ответа получить message и показать его или же что-то другое с ним сделать. Было бы интересно еще научиться по api генерировать специфичное тело ответа

К примеру, передавать post('http://httpme.tk/403'), а в body запроса тело вроде {«message»: «error»}, которое и вернется в ответе

unsstrennen Jul 20 2020 at 19:11

Думаю, я внесу эту правку. Спасибо!

SIDOVSKY Jul 20 2020 at 14:46

В качестве альтернативы: httpstat.us

UFO just landed and posted this here

RouR Jul 20 2020 at 14:48

http://httpbin.org/status/500
https://postman-echo.com/status/500
А ещё там есть богатая документация и разные методы, не только возврат status codes (например вернуть текущий ip, или сделать delay и т.п.).

p0poff Jul 20 2020 at 19:11

Если бы он умел понимать любой хвост урла, типа:
http://httpbin.org/status/500/anything/anything
ему бы цены не было

unsstrennen Jul 20 2020 at 19:11

Я добавлю это, спасибо!

resetme Jul 20 2020 at 14:55

Вы изобрели то, что давно существует и что уже давно используют:

github.com/postmanlabs/httpbin

+10

visirok Jul 29 2020 at 23:09

Два предложения по расширению:
1. Уметь отвечать с заданной задержкой (в том числе практически бесконечной)
2. В больших корпорациях доступ к Интернету всё сильнее ограничиваетя. Получить доступ к Вашему и подобным серверам может быть сложно. Хорошо бы иметь возможность просто устанавливать такой сервер как proxy на десктопе разработчика,

unsstrennen Jul 29 2020 at 23:12

Спасибо, я работаю над сервисом, учту ваши пожелания.

Show the best of all time