Да, как удобно. Можно в отдельной базке, можно в отдельном сервисе, если там много логики над данными

Если локально в файликах, то .py/.json/yaml/xml берешь, что тебе удобнее парсить просто. Можно вообще в nametuple какие-нибудь упаковать

принято, вот как раз nametuple или что-то подобное подойдет наверное.

посмотри еще
https://docs.python.org/3/library/dataclasses.html
https://python.plainenglish.io/why-you-should-start-using-pythons-dataclasses-cd6a73ae5614

о, отлично, посмотрю

Все, как и в разработке. На голых примитивах далеко не уехать. Трестируемая бизнес логика все равно крутится вокруг каких-то сущностей. И чем сложнее объекты, тем больше профита от переиспользования реальных моделей. Конкретно с currency - это может быть и enum, ибо все эти константы стандартизованы. Но если у вас там какой-то свой currency / exchange rate сервис, то возможно имеет смысл вытягивать актуальную инфу в рантайме, обратившись к соответствующему эндпоинту. Зависит от того, что тестируется.

не, в данном случае условная currency — стандартизированная сущность, enum и датаклассы хорошо выполняют задачу.

про переиспользование реальных моделей вот вообще непонятно

В зависимости от того, есть ли доступ к коду приложения или нет, и на каком уровне пишутся тесты, можно либо напрямую дёргать соотвествующие объекты, либо паковать модель в отдельный модуль. Хотя, последний вариант редко практикуется. Нужно архитектурно изначально на это закладываться. Если ни один из вариантов выше не актуален, то что ж, тогда нужно своё создавать. Но я бы все равно подсмотрел в реальный код приложения, как все эти сущности там описаны, чтобы не изобретать велосипед, и учесть сразу все нюансы.

а, справедливо. в данном кейсе доступа напрямую к core и коду нет, замечание про реальноое описание сущностей учту, спасибо

Про архитектуру вообще хороший вопрос, для ui есть page object , а для api? Тесты каждого микросервиса в отдельный модуль, но когда начинаем совокуплять интеграцию получается нужно иметь более сложную модель. Опять же доступа к коду разработки нету

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

У фронтндеров, или любых других потребителей апи спросите, как у них сделано в конце концов

Я делаю через фасад
Удобно и структура получается аналогичная дереву API:

/api/lists/select
self.client.api.lists.select()

Коллеги, хочу сделать прослойку, которая возвращает токен для soap. Запустил простейший сервер, который получая запрос GET высылает запрос на авторизацию используя credentials моего тех пользователя и возвращает токен,который в свою очередь возвращается конечному пользователю, который запросил токен через мой сервер прослойку. Все бы ничего, но я не могу создавать кучу сессий ибо пул ограничен. Можете подкинуть идею как сделать так, чтобы создавать минимальное количество сессий? При этом сессия живёт n секунд, если её не убить ранее. Надеюсь я понятно выразился :)

Такая прослойка нужна, чтобы юзеры не должны были создавать своих пользователей и спокойно использовали апи не заморачиваясь авторизацией

не можешь создавать кучу сессий куда?

к провайдеру токенов?

Да

сессия = коннект?

Высылается запрос на создание сессии использую пароль, юзернейм, в ответе получаешь секретный ключ, который потом высылаешь в следующих запросах