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

Явные ids задают читаемые имена параметров в идентификаторах собранных тестов и отчётах pytest. Они не меняют сами значения параметров и не влияют на логику теста, но упрощают диагностику падений, выбор конкретного случая и анализ CI-отчётов.

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

При параметризации один тест превращается в несколько отдельных тестовых случаев. Для различения этих случаев pytest формирует node ID, включающий имя теста и идентификатор параметра.

Автоматически сформированные идентификаторы не всегда понятны: для сложных объектов они могут быть техническими, длинными или нестабильными. Явные ids решают проблему читаемости и делают адрес конкретного сценария более предсказуемым.

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

Без явных ids падение параметризованного теста может выглядеть неинформативно: из отчёта трудно понять, какой бизнес-сценарий связан с конкретным значением. Это замедляет локальный повтор ошибки и усложняет фильтрацию тестов по node ID.

Неверно считать ids частью тестовых данных. Если изменить id, поведение теста не изменится, но могут перестать работать команды или CI-настройки, которые обращаются к тесту по старому node ID.

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

Явный id становится частью имени параметризованного случая. Например:

import pytest

@pytest.mark.parametrize(
    "role",
    ["admin", "user"],
    ids=["administrator", "regular-user"],
)
def test_access(role):
    assert role in {"admin", "user"}

pytest покажет случаи примерно как test_access[administrator] и test_access[regular-user]. Значения role при этом останутся admin и user; ids используются только для идентификации и отображения.

Для фикстуры ids можно задавать аналогично через параметр ids. Также допустима функция, которая получает значение параметра и возвращает строковый идентификатор. Если функция возвращает None, pytest использует стандартный способ формирования id для этого значения.

Хороший id описывает сценарий, а не дублирует внутреннее представление объекта: empty-cart, expired-token, admin-user. Следует избегать случайных данных, временных меток и длинных строк, поскольку изменение id влияет на адрес теста в отчётах и при выборочном запуске.

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

В проекте есть параметризованный тест прав доступа для ролей. Автоматические ids содержат только значения перечисления, поэтому в CI трудно отличить сценарии с истёкшей подпиской и с обычным пользователем.

Можно оставить автоматические ids: это не требует изменений, но диагностика остаётся слабой. Можно использовать один общий id для всех случаев, однако он не различает сценарии и может сделать отчёт неоднозначным.

Выбран вариант с явными ids, описывающими бизнес-смысл каждого параметра. В результате падение сразу указывает на нужный сценарий, а разработчик может повторить его по конкретному node ID. При этом сами входные значения и проверяемое поведение не меняются.

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

Вопрос: Меняет ли явный id значение, переданное в тестовую функцию?

Ответ: Нет. Id — это метаданные параметризованного случая. Тест по-прежнему получает исходное значение, а id используется pytest для имени node, вывода и фильтрации.
Вопрос: Что произойдёт, если функция генерации ids вернёт None для одного параметра?

Ответ: Для этого параметра pytest применит стандартное формирование идентификатора. Это позволяет переопределить имена только для сложных или важных случаев, не описывая вручную весь набор параметров.
Вопрос: Почему изменение явного id может сломать выборочный запуск, хотя тестовая логика не менялась?

Ответ: Node ID входит в адрес тестового случая. Если CI, локальный скрипт или документация запускают тест по полному node ID, изменение id изменит этот адрес. Поэтому ids стоит делать осмысленными и достаточно стабильными, а не строить их на случайных или изменяющихся данных.