Что происходит с параметром при косвенной параметризации pytest через фикстуру?
При косвенной параметризации значение не передаётся непосредственно в аргумент тестовой функции. pytest сохраняет его как параметр фикстуры, а фикстура получает значение через объект request и использует его при подготовке тестовых данных.
Параметризация появилась как способ запускать один сценарий с несколькими наборами входных данных без копирования тестовой функции. Косвенная параметризация дополнительно отделяет описание входных вариантов от их преобразования в ресурсы или объекты, необходимые тесту.
Это особенно полезно, когда тесту нужен не сам идентификатор или конфигурация, а созданный по ним объект: запись в базе данных, временный каталог или клиент внешнего сервиса.
Допустим, тест должен проверять одну операцию для нескольких ролей пользователей. В параметрах удобно хранить короткие значения вроде имени роли, но фикстура должна по этому имени создать полноценного пользователя.
Если передавать такие значения напрямую в тест, логика подготовки окажется внутри тестовой функции. Это увеличивает дублирование и смешивает проверяемое поведение с настройкой окружения. Если же забыть косвенную параметризацию, pytest будет искать фикстуру с именем параметра как обычный аргумент теста или передаст параметр не тому уровню.
При косвенной параметризации pytest направляет значение в фикстуру, указанную в качестве параметра. Внутри фикстуры это значение доступно как request.param; затем фикстура может преобразовать его в нужный ресурс и вернуть результат тесту.
Здесь тест запускается дважды. Строки admin и reader сначала становятся параметрами фикстуры user, а уже возвращённые фикстурой словари попадают в тест.
Ключевой компромисс состоит в разделении ответственности: тест описывает варианты поведения, а фикстура — способ подготовки данных. Это повышает переиспользуемость, но усложняет навигацию по тесту: источник фактического объекта находится в фикстуре, а не рядом с утверждением.
Косвенная параметризация не означает автоматическое создание объектов любого типа. Фикстура сама должна обработать request.param, а при отсутствии этого обращения параметр может фактически не использоваться. Также важно различать параметризацию фикстуры через params и косвенную параметризацию теста: это разные способы задать входные значения и разные места, где объявлены варианты.
В тестах API нужно проверить доступ для нескольких ролей. Вариант с отдельным тестом на каждую роль прост для чтения, но приводит к дублированию запросов и проверок. Вариант с прямой параметризацией передаёт в тест только названия ролей, однако оставляет создание пользователя и токена внутри теста.
Выбран вариант с косвенной параметризацией через фикстуру. Фикстура создаёт пользователя, выдаёт ему необходимые атрибуты и возвращает готовый контекст, а тест занимается только проверкой доступа. В результате добавление новой роли требует изменить список параметров, не копируя подготовительный код.
Минус решения — возможная потеря прозрачности: чтобы понять, какие именно данные получает тест, приходится открыть фикстуру. Поэтому имена фикстур и параметры должны быть предметными, а сложную подготовку лучше сопровождать небольшими отдельными фикстурами.
Да, в типичном случае имя в parametrize должно соответствовать аргументу теста, который является фикстурой. Именно по этому имени pytest связывает параметр с фикстурой и применяет косвенную передачу. Переименование только в одном месте нарушит связывание или изменит смысл параметризации.
Значение будет рассматриваться как параметр самого теста, а не как request.param фикстуры. Фикстура при этом не получит соответствующее значение через request.param; в зависимости от объявления фикстуры тест либо не сможет корректно разрешить зависимости, либо будет проверять не тот сценарий, который предполагал автор.
Параметризацию фикстуры уместно выбирать, когда один набор вариантов должен автоматически применяться ко всем тестам, использующим эту фикстуру. Косвенная параметризация теста лучше, когда варианты нужны только конкретному тесту или группе тестов. Первый вариант повышает переиспользуемость, но может неожиданно увеличить число запусков других тестов; второй точнее ограничивает область действия, но требует повторять список вариантов там, где он нужен.