это не фикстура, это часть сценария

Да с чего ты взял

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

фикстура = поднять, подготовить

И какая разница че готовить?

а не добавить нового юзера

добавлять нового юзера?

Изначально риторика была примерно такая "никаких запросов в фикстурах"

их там и не должно быть

А что там должно быть? Если мне на каждый тест нужен юзер и единственный способ это сделать это отправить запрос на его создание - почему я не могу делать это в фикстуре?

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

так как надо-то в итоге? пример кода на гитхабе или где угодно приведите пожалуйста

misc.py >>

async def add_some_dababeb():
        # тут блять

что это значит?

ой, ты удалил

Бот удалил

на меня пожаловались?

Но я зацепился больше за то, что авторизация в фикстуре это плохо и всё тут.
Сколько раз пользователь вводит авторизационные данные, переходя из раздела в раздел условного веб-приложения? Один раз (в общем, не рассматриваю частные случаи)
Авторизован пользователь или нет это некое состояние. Как и запрос, который отправлен на сервер воспринимается последним или авторизованным или нет.
С точки зрения тест-кейса, Вы сказали, что авторизация - часть сценария,  согласен, но в разделе предусловий, типа "Пользователь авторизован в системе". Предусловия в том числе это подготовка состояния.
А как мы выяснили ранее фикстура это про подготовку состояния. Так почему категорически нельзя авторизоваться в фикстуре?
Причем я не утверждаю, что это всегда правильный путь (в сообщениях ранее я призывал всегда руководствоваться здравым смыслом), а скорее не могу понять, почему так нельзя.
В дискуссии с Вами, я увидел только доводы "у меня в компании".

Нет твоего мэйна разбанили

коллегу по работе, с которым я много пью