а если я указываю -app <приложение>, которое только что создал, пишет No images to push

Всем привет. есть фреймворк для работы с апи приложения. Сделано это как один класс, в котором перечислены все методы реализующие функционал. Но вот беда в том, что методов становится все больше и больше, и это потихоньку превращается в большую помойку.Мысль сразу разбить все это на классы. Вопрос возможно очевидный, но тем не менее, для апи фреймворка также применим паттерн page object как и для веба?  Можно также прибегнуть к множественному наследованию, но идея так-себе.
В идеале хочется иметь одну точку входа, которая уже распределяла бы в зависимости от метода, к какому классу обратиться

а почему не хотите создать базовый класс, в котором будет просто обработка post/get/etc запросов, и от него наследовать классы, которые уже бизнес-логику реализовывают? например, класс UserService(BaseService), список методов get_user(), create_user(), update_user(), deactivate_user()

да можно и так, изначально просто задумывалось, что один класс будет что-то типа обертки над requests. Ну и чтоб мы вызывали как раз только его, и все методы тоже как-то хранить\распределять в нем, чтобы не запоминать все эти классы типа UserService и иже с ним

может просто есть какие-то паттерны которые это реализуеют

я так слегка пробежался по основным, но либо я что-то не так понимаю, либо ни один не подошел )

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

паттерны ничего не реализуют, это правила организации кода, при которых шансы того, что потом все не превратится в месиво в плане поддержки и развития - несколько выше. Единый класс при любой организации будет похож на месиво рано или поздно, так что стоит таки посмотреть на вариант с наследованием (или иным разделением) для разделения методов работы по конкретным экндпоинтам и/или логическим группам

честно сказать, что я, если бы пришел на ваш проект, как автоматизатор, намного сильнее бы расстроился, если бы увидел один класс и 200 методов в нём)

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

к слову для маленьких проектов вполне нормальный вариант :)

спасибо за ответы, это развеяло какие-то сомнения. вопрос был еще про page object, он также применим и для фреймворка тестирования api? можно пока есть возможность все переписать используя его. просто везде где он есть упоминается  именно в контексте селениума, веба и вот этого всего

согласен, но хочу подтолкнуть к мысли, что все-таки разделение на сущности на порядок удобней когда появляется больше функционала

как вы себе это представляете? :) В апи нет страниц, там есть эндпоинты, сервисы (или логические группы) работащие в режиме запрос-ответ

ApiObject)

Так ведь UI это API

В чем проблема?

https://github.com/sniiick/education-mail-qa-python/blob/main/lection10%20-%20Api%20%232/code/api/client.py

вот такую штуку просто делаю обычно и все. если методов дофига - разделяю на логические классы и наследую от базового, в котором логика логина, обработка запросов и логгирование

и всего делов то

Если openapi есть, то можно такую штуку прикрутить и автогенерить https://github.com/swagger-api/swagger-codegen