справедливо

не. Фикстурой с жизнью в сессию получаешь значение и в каждый тест отдаешь. Но! изменить его ты не сможешь все равно

Тогда фикстуры получается не рашат проблему...

Бывает что проблема не решается ЯПом, а лишь правильной архитектурой

Буду искать решение, всем спасибо за фидбек без токсичности, очень приятно

короче, судя по тем строчкам, что у тебя есть.

Несколько утверждений, которые возможно кто-то тут оспорит, но думаю в целом верные:

1. Переменные вызываются и читаются у тебя правильно с точки зрения питона.
2. с точки зрения pytest этот механизм работает каким-то образом, который может перестать работать. например, тест запустится в другом порядке, и вот твои методы уже невпопад читают\изменяют переменную.
3. Исходя из пункта (2) и то что ты видишь сейчас, у тебя, скорее всего, что-то такое и происходит.
4. Если есть возможность сделать тесты независимыми, то лучше их сделать. Например, вместо теста (1) создать юзера (сохраняем ID нового юзера в переменную) и (2) удалить существующего юзера (читаем переменную), то лучше переписать так:
(1) создаем юзера, проверяем, что все ок
тут варианты могут быть второго теста:
(2) находим какого-нибудь юзера из базы, которого можно удалить, получаем его ID, удаляем.
или
(2) создаем юзера для этого теста в рамках фикстуры, фикстура вернет в тест ID нового пользователя, используем ID для удаления

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

Попробую утром переписать, спасибо большое

Согласен

подскажите пожалуйста
Использую профили гугл хром в selenium
Добавляю аргумент с расширением экрана 500 на 500
В после загрузки сайта делаю скриншот
И в каждом профиле, размер элемента разный,
Не при каждой загрузки сайта, а именно при использовании  профиля
т.е  профиль 1 = расширение скриншота 500х412
профиль 2 = 500х380 и т.д
Как это пофиксить

pytest, aiohttp.test_utils.TestServer

Поднимаю несколько заглушек, с которыми общается тестируемый сервис. В конце некоторых сценариев необходимо убедиться, что в определённые заглушки приходили запросы от трестируемого сервиса. Фикстуры передают сущность заглушке таким образом:

yield server: aiohttp.test_utils.TestServer

Вопрос: можно ли как-то добраться до истории запросов в TestServer?
ПС: мне пока приходит в голову ещё один костыль - добавить поле в сущность заглушки, которое будет хранить дикт с запросами и в конце тест-кейса пользоваться им, но этот вариант мне не нравится…

Аиохттп пишет в логи запросы, смотри в ту сторону

ну я что-то такое пытаюсь найти, но пока не нашёл где они коллектятся

Нигде, отфильтровываются по уровню логгера

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

я сделал проще, поднимаю в треде SimpleHttpServer с кастомным request handler. В нем же все запросы (обработанные) сохраняю прямо в отдельный объект. Далее из тестов смотрю что в объекте есть то что мне нужно

в пине 23 пункт - мое решение и то чем регулярно пользуюсь

Да, я вижу все необходимые запросы. Если я тебя правильно понял - мне нужно написать хэндлер для логгера aiohttp.access, затем парсить сообщения и хранить удобным мне образом?

да, идея примерно такая

а где у тебя поднимается мок? учти, что доступ к этому объекту будет только у тех потоков, которые на одном уровне с твоим моком