Краткий ответ

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

Поведение можно изменить настройкой empty_parameter_set_mark: выбрать skip, xfail или fail. Поэтому окончательный результат зависит не только от пустого набора, но и от политики проекта.

Исторический контекст

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

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

Постановка проблемы

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

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

Подробное решение

При пустом наборе параметров pytest создаёт специальный параметризованный тестовый элемент с маркером пропуска. Функция теста не вызывается, поэтому её утверждения, побочные эффекты и обычная логика тела не выполняются.

Минимальный пример:

import pytest

@pytest.mark.parametrize("value", [])
def test_value(value):
    raise AssertionError("тело не выполняется")

В отчёте такой элемент обычно отображается как SKIPPED. Это отличается от PASSED: пропуск не подтверждает, что проверяемое поведение корректно.

Настройка empty_parameter_set_mark задаёт реакцию на пустую параметризацию:

skip — создать пропущенный тест; это значение по умолчанию;
xfail — считать отсутствие параметров ожидаемой недоступностью проверки;
fail — завершить сборку с ошибкой.

Строгий режим fail полезен, когда пустой набор свидетельствует о дефекте генерации данных. skip лучше подходит для условных наборов, которые законно могут быть пустыми. xfail стоит применять осторожно: он сообщает об ожидаемом отсутствии проверки, но может скрыть проблему, если причина пустого набора изменилась.

Ситуация из практики

Тесты API получают список поддерживаемых версий из отдельного файла. После фильтра по текущей платформе список оказался пустым.

Первый вариант — оставить поведение по умолчанию. Плюс: CI не падает из-за платформы без поддерживаемых версий. Минус: тест фактически ничего не проверяет, а пропуск может остаться незамеченным.

Второй вариант — настроить fail. Плюс: ошибка в загрузке или фильтрации данных обнаруживается сразу. Минус: нужно отдельно обработать действительно допустимые платформы без сценариев.

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

Что кандидаты часто упускают

Считает ли pytest пустой параметризованный тест успешно пройденным?

Нет. По умолчанию он получает статус skipped, а не passed. Это важно для метрик покрытия сценариев: зелёный запуск с пропущенным тестом не означает, что проверка реально выполнялась.

Могут ли фикстуры теста изменить результат пустой параметризации?

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

Когда лучше выбрать fail, а когда оставить skip?

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