Анализ покрытия кода
Тема дорожной карты · Python Programming
coverage.py измеряет, какие строки и ветки выполняются под твоими тестами. Удобно запускать через pytest и pytest-cov, пороги задавать в pyproject.toml или .coveragerc. Воспринимай покрытие как датчик дыма, а не как цель: 100% строк со слабыми ассертами не значит ничего. Включай покрытие веток (--cov-branch), чтобы видеть пропущенные if/else, а сгенерированный код или блоки __main__ исключай через # pragma: no cover. Для параллельных прогонов объединяй отчёты с помощью coverage combine.
Как это работает
Анализ покрытия кода в Python строится на pytest (de facto стандарт) или stdlib unittest. Тесты лежат в tests/ и следуют конвенции test_*.py. pytest обнаруживает тесты автоматически; ассерты — обычный assert (pytest переписывает их для богатого вывода ошибок). Fixtures (@pytest.fixture) — переиспользуемый setup/teardown; параметризация (@pytest.mark.parametrize) гоняет один тест на множестве входов. unittest.mock (или pytest-mock) подменяет коллабораторов в изоляции. coverage.py меряет покрытие по строкам/ветвям.
Когда применять
Тестируйте публичную поверхность каждого модуля с бизнес-логикой; пропускайте тривиальные геттеры и one-line обёртки. Цель — быстрые unit-тесты на чистые функции + integration-тесты на границе (БД, HTTP, файловая система). Mock-айте сайд-эффекты, которыми не управляете (сеть, время, случайность); over-mocking своего кода тестирует mock, а не код. Гоняйте pytest в CI на каждый PR; coverage — дымовой сигнал, не цель (погоня за 100% поощряет тривиальные тесты).
Типичные ошибки
Ловушки Анализ покрытия кода: тесты, зависящие от порядка (изолированные fixture, не модульные глобалы); тесты, бьющие в реальную сеть или БД без маркировки (@pytest.mark.slow, @pytest.mark.integration) — CI взрывается; тестирование деталей реализации вместо поведения (любой рефакторинг рушит тест); flaky-тесты, на которые забивают (каждый подрывает доверие, пока вся suite не теряет смысл). Карантинить, потом чинить или удалять.