Тестирование декоратора, который оборачивает маршруты API

Question

Я создаю API для отдыха, и я делал маршруты для API и наткнулся на проблему.Я использую колбу restplus для создания API и зефира для проверки JSON, отправленного клиентом.

Мой дизайн: я использую декоратор, который используется для обертывания каждого маршрута API.этот декоратор проверяет json, отправленный клиентом, по схеме зефира, и если json проверяет, то декоратор запускает маршрут API.В противном случае, если json делает недействительным, когда он сверяется со схемой, он возвращает ошибки, которые он получил, когда сделал недействительным json обратно клиенту без выполнения маршрута.

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

Моя единственная проблема в том, что я понятия не имею, как unit проверить это.Я написал тесты для конкретных схем json с маршмеллоу, чтобы проверить, не вызывают ли они правильные ошибки валидации, когда им передаются неверные данные.Однако теперь мне нужно проверить маршруты API, чтобы проверить, возвращают ли они ошибки проверки, возникшие в схемах.Это похоже на многократное повторение модульных тестов, потому что я проверяю те же ошибки при тестировании схем и снова, когда я тестирую маршруты / декоратор API.

Поэтому, ребята, есть ли какие-либо рекомендациио том, как я должен тестировать это.Стоит ли конкретно тестировать маршруты API, отдельно декоратор и схемы отдельно?Или я должен проверить только маршруты API, чтобы убедиться, что они возвращают правильные ошибки, возникающие в схемах?

Заранее спасибо.

Answer 1

Это может быть вопросом мнения.

Я не думаю, что полезно тестировать все схемы, если только они не содержат некоторый пользовательский код, такой как настраиваемые поля, валидаторы и т. Д. Нет необходимости тестироватьсам зефир, так как он уже широко освещен в собственных тестах.Таким образом, тестирование схемы зефира будет служить только для проверки того, что вы ввели правильные имена полей и валидаторы.Это было бы довольно многословно для низких выгод, ИМХО.

Я бы протестировал декоратор: создайте фиктивный тестовый маршрут, украсьте его, проверьте правильность возвращаемой ошибки.

Решите, стоит ли этотестирование всех маршрутов на все виды ошибок зависит от васПока ваш декоратор тестируется, тестирование маршрутов просто проверяет, что декоратор применен к маршруту с правильной схемой.

Некоторые утверждают, что, наоборот, они заботятся только о самом API, и онинужно только проверить маршруты.Но это означает тестирование всех случаев на всех маршрутах, так что это много дублирует.И я не думаю, что это можно квалифицировать как модульное тестирование , а скорее интеграционное тестирование .

Обратите внимание, что вы можете попробовать использовать веб-теги (поддерживаются командой зефира) для замены вашегодекоратор, но я не знаю, как легко интегрировать в flask-restplus.