Комментарии 7
Какой замечательный фреймворк ...
1. Вроде уже давно третий питон-то. Я уж и забыл, как эта строчка выглядит.
https://github.com/ScaLseR/petrovich_framework/blob/main/api/api.py#L2
2. А зачем хранить урлу в словаре? + эта переменная класса вообще не используется в коде
https://github.com/ScaLseR/petrovich_framework/blob/main/api/api.py#L16
3. А зачем жестко задавать заголовки и пихать их в каждый метод. Сомневаюсь, что для методов GET и DELETE нужен {'Content-Type': 'application/json; charset=utf-8'}.
https://github.com/ScaLseR/petrovich_framework/blob/main/api/api.py#L14
requests из коробки удачно работает с заголовками исходя из переданных параметров: params, json, data. Обычно не требуется их явно указывать.
4. Велосипед с десериализацией впечатляет. Но удобнее использовать готовые решения. Например, pydantic. Заодно, может и от валидации json-схем отказаться. Ну как минимум, тип данных в ответе pydantic проверит
5. Для примера взят слишком простой функционал. Банально даже авторизации нет. А если несколько "апи-коннекторов" нужно в тесте. Как будешь с сессией вопрос решать?
(1) и (2) – недосмотрел, поправил. Спасибо!
Насчёт (3) – для данного API не предполагается отправка заголовков, оставил как пример.
Что касается (4) и (5) – статья направлена на новичков в автотестировании (постарался написать об этом во вступлении, для правильных ожиданий). Мой план был в том, чтобы показать, как всё сделать как можно проще, без использования сторонних библиотек.
Среди идей для будущих статей есть темы про более глубокие вопросы из автотестирования. Буду держать в голове ваш комментарий при работе над этими темами, спасибо!
(3) Тогда происходит явный самообман. Ты считаешь, что заголовки не нужны, но они все равно передаются. У тебя ж в каждом методе в аргументах: headers=self._HEADERS. Понятное дело, что сервер настроен так, что игнорирует ненужные заголовки, но это ж не хорошо, если в запрос идет то, что мы не хотим передавать.
Я бы, как минимум, отдал бы управление заголовками в метод для конкретного "апи-коннектора". Надо будет - сами передадут, что нужно в kwargs:
https://pastebin.com/yA4imide
В более сложном варианте, я вообще бы отказался от части аргументов, заменив их на **kwargs. Но тогда придется рефакторить текущий код:
https://pastebin.com/WuzaWqax
При использовании kwargs позволяем передавать произвольное количество аргументов функции, и функция может вести себя непредсказуемо. Тем самым отладка нашего кода становится гораздо сложнее, а сам код требует очень тщательного написания документации. Я стараюсь не использовать неконтролируемое аргументирование в своем коде, ведь - Явное лучше, чем неявное. - Дзен Python
Разбираемся с основами автотестирования: пошаговая инструкция по созданию собственного фреймворка для проверки API