Идиомы pytest: переписывание assert, обнаружение тестов, маркеры и петля отладки

Почему голый assert лучше self.assertEqual

Задайте себе вопрос: почему unittest пишет AssertionError: False is not true, а pytest показывает каждое подвыражение — ответ определяет, как вы организуете каждую общую проверку в кодовой базе.

pytest на старте устанавливает хук импорта (meta-path finder). Когда он импортирует модуль, который собирается коллектить — тест-модуль, conftest.py или зарегистрированный плагин, — он разбирает исходник в AST, переписывает каждый оператор assert в код, записывающий значение каждого подвыражения, перекомпилирует и кэширует переписанный байткод в специально помеченном .pyc. В этом весь фокус знаменитого вывода при падении:

# test_pricing.py — собирается, поэтому assert ниже переписан при импорте
def apply_discount(cents: int, pct: int) -> int:
    return cents * (100 - pct) // 100

def test_discount():
    assert apply_discount(1999, 15) == 1700
# E       assert 1699 == 1700
# E        +  where 1699 = apply_discount(1999, 15)

Не нужно помнить assert-методы, не нужен self.assertEqual(a, b) — переписанный код восстанавливает, во что вычислилась каждая сторона. Команды кусает граница: переписываются только модули, которые pytest сам импортирует для сбора. Вынесите общие проверки в tests/helpers.py — assert там по-прежнему поднимется при провале, но как голый AssertionError без значений: диагностика исчезла ровно там, где вы её централизовали. Фикс — одна строка, размещённая до первого импорта хелпера (стандартное место — корневой conftest.py): pytest.register_assert_rewrite("tests.helpers"). Два смежных факта: файлы conftest.py переписываются автоматически, а запуск Python с -O вырезает операторы assert целиком — сьют под -O проходит вхолостую, поэтому pytest об этом предупреждает.

Обнаружение: сначала импорты, ваш код выполняется независимо от желания

Получив целевую директорию, pytest собирает файлы по маскам test_*.py и *_test.py; внутри них — функции с префиксом test_ и классы с префиксом Test, не определяющие __init__. Перед импортом тест-модуля он импортирует цепочку conftest.py от rootdir вниз до директории модуля — так фикстуры и хуки становятся доступны без импортов. Структурное следствие — инцидент из вступления: сбор означает импорт. Всё, что выполняется на уровне модуля в тест-файле — или в чём-то, что он транзитивно импортирует, — выполняется до запуска тестов. Один модуль, строящий движок БД, читающий отсутствующую переменную окружения или создающий синглтон приложения при импорте, даёт ошибку сбора; pytest печатает Interrupted: 1 error during collection и не запускает ничего. Падающий conftest.py хуже: он отравляет всё своё поддерево. Отсюда дисциплина: верхний уровень тест-модулей — только импорты чистого кода, а всё с побочными эффектами уезжает в фикстуру, где провал ограничен тестами, которые её запросили. При подозрениях pytest --collect-only -q показывает, что будет запущено: на репозитории в 5 000 тестов один сбор занимает несколько секунд — это же ваш нижний предел для pytest -k one_test.

Балласт unittest, от которого можно избавиться: pytest запускает обычные функции, так что церемония class TestX(unittest.TestCase) и self.assertEqual ничего не добавляет — и стоит совместимости: методы TestCase не могут принимать фикстуры параметрами, а @pytest.mark.parametrize на них не работает. Группировка, когда нужна, — голый класс с префиксом Test без базового класса.

raises, warns и маркеры без фольклора

import pytest

def test_rejects_negative():
    with pytest.raises(ValueError, match=r"negative amount: -\d+"):
        charge(-500)          # держите блок в ОДНУ строку — строку под тестом

@pytest.mark.xfail(reason="округление полуцента, баг #4231", strict=True)
def test_half_cent_rounding():
    assert price_total([("X", 1, 0.005)]) == "0.01"

pytest.raises(..., match=...) выполняет re.search по строковому представлению исключения — это регулярка, экранируйте скобки. Классическая самострельная рана — широкий блок with: внутри три строки подготовки, одна из которых поднимает то же исключение по другой причине, и тест проходит, пока тестируемый код сломан. Внутри держите ровно падающий вызов. pytest.warns устроен так же для предупреждений. Маркеры честно: skip документирует факт («на этой платформе нет Postgres»), skipif делает его условным, а xfail документирует известный баг, продолжая запускать тест. Флаг, отделяющий дисциплинированные сьюты от гниющих, — strict=True: xfail-тест, неожиданно прошедший (XPASS), валит сьют, и починенный баг всплывает сразу, а не прячется год за протухшим маркером. Кастомные маркеры вроде @pytest.mark.slow обязаны быть зарегистрированы в [tool.pytest.ini_options] markers, иначе каждое использование сыплет PytestUnknownMarkWarning, — а --strict-markers поднимает неизвестные маркеры до ошибок сбора: единственное, что стоит между вами и @pytest.mark.slwo, молча не выбирающим ничего.

Петля отладки и что на самом деле видит CI

Петля, делающая сьют в 2 000 тестов пригодным для жизни: полный прогон краснеет, дальше pytest --lf -x — только последние упавшие, остановка на первом провале — до зелёного, затем один полный прогон для подтверждения. --ff запускает упавшие первыми, не отбрасывая остальное; -k "payments and not slow" выбирает по выражению над именами; -x — флаг нетерпения. Состояние для --lf живёт в .pytest_cache. CI же видит только код выхода, и таблица короткая: 0 — всё прошло, 1 — есть упавшие, 2 — прервано, 3 — внутренняя ошибка, 4 — ошибка использования, 5 — ничего не собрано. Код 5 — ловушка: переименуйте директорию или ужесточите фильтр -m, и стадия с нулём тестов краснеет — поведение корректное, понедельник испорчен. Команды, «чинящие» это через pytest -m smoke || true, замаскировали код 1 вместе с кодом 5: упавшие smoke-тесты теперь проходят CI. Честный фикс обрабатывает 5 явно и позволяет 1 валить джобу.