этот путь ведёт к тому, что conftest будет нагромождён хелперами

фикстура - подготовка

а прям в файле тестов нельзя?

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

а все что там от теста к тесту меняется в хелпер не выноси

ну это уже пронуха(

а вообще...

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

так что я согласен

Моя позиция простая:
1. чем тупее код, тем проще его править
2. дублирование исправить проще чем излишнюю унификацию

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

Хорошо, если вышла правильная структура.

Юзай передачу данных о файлах с фикстурами в виде списка? На крайняк реализуй фикстуры, что будет проксировать

Я понимаю, что так можно. Наиболее весомым аргументом для меня является то, что фикстура должна быть подготовкой, а не хелпером. Если сравнить минусы моего варианта с минусами варианта Тишки:

Вариант Тишки(хелпер в отдельном файле, дёргает его фикстура):
- Фикстура использующая этот хелпер может дёргаться только из теста, соответственно нельзя использовать хелпер в другом хелпере, а если попытаться под это сделать ещё фикстуры - мы придём как раз к тому самому нагромождению и излишней унификации.
- Всё раскидано на файлы conftest.py и misc.py(например).
- 10 часто использующихся хелперов == 10 передач фикстур для их выполнения в каждый тест... Конечно можно сделать класс с огромным количеством хелперов и передавать его инстанс, но в этом есть свои минусы(см. конец текста с примером).

Вариант мой(с inspect'ом):
- В коде хелпера мы жёстко привязываемся к имени фикстуры.

Теперь плюсы второго варианта:
- Мы импортируем хелпер в файл с тестами и просто дёргаем его
- Можем использовать где угодно... Пример: 30 из 100 тестов начинаются с 3 одинаковых запросов для достижения определённого состояния, это можно легко вынести в отдельный файл repeatable_steps.py(например) и использовать функцию send_request 3 раза(с фикстурой так не выйдет)
- На уровне файла с тестами идёт импорт хелперов и потом их банальное использование.. Напомню: моей задачей было избежать регулярный проброс большого количества фикстур в вспомогательные функции для тестов - оба варианта с этим справляются, но вариант Тиши приводит к регулярному пробросу фикстур в тест-кейсы.

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

async def send_request(
        from_: aiohttp.test_utils.TestServer, 
        data: dict, 
        query: dict = None, 
        path: str = None, 
        method: str = 'GET'
):
    service = get_fixture_by_name('service')
    clt = get_fixture_by_name('client')
    # get specific route+hdrs for req
    # do req: specific stub -> testing service

В conftest.py 11 заглушек, с которыми общается тестируемый сервис. С этой функцией мы передаём только заглушку и она может быть любой.

@pytest.fixture(scope="session")
def auth_new_user(signup):
   url = "http://127.0.0.1:10001/auth/sign_in"
   response = requests.post(url, json=signup)
   response_body = response.json()
   token = response_body['data']
   header_token = {'Authorization': 'Bearer: %s' % token}
   return header_token

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

fixtures_auth.py или auth_plugin.py
подключать к conftes.py как плагины
можно и просто директорию fixtures/auth.py
вопрос как вам самим нравится, но ответ да, все как вы сказали

как плагины это как?

благодарю

а импортировать данные в фикстуры это дурной тон? или все таки норма