Работали ли вы с тестами в Python

Что проверяют

Писали ли вы тесты сами или только запускали чужие. Интервьюера интересует не список библиотек, а понимание, что проверять на каком уровне, как изолировать зависимости и почему прогон обязан давать один и тот же результат.

Как отвечать

Назовите стек и покажите привычки. Основной инструмент сейчас pytest: простые функции вместо классов, обычный assert, фикстуры вместо setUp, параметризация вместо копий теста.

@pytest.mark.parametrize("raw,expected", [("10", 10), (" 7 ", 7)])
def test_parse(raw, expected):
    assert parse_int(raw) == expected

Дальше стоит упомянуть:

• фикстуры с разной областью видимости и общий conftest.py, чтобы подготовка не расползалась по файлам;
• изоляцию: monkeypatch для переменных окружения и атрибутов, unittest.mock для зависимостей, заглушка вместо похода в сеть;
• соотношение уровней: много быстрых модульных тестов, меньше интеграционных с настоящей базой в контейнере, единицы сквозных;
• покрытие как подсказку о непроверенных ветках, а не как цель;
• требование к прогону в сборке: без сети, без зависимости от порядка, без общего состояния между тестами.

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

Где спотыкаются

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

Патчат не то место. Если модуль сделал from requests import get, подмена requests.get уже ни на что не влияет: патчить надо имя там, где оно используется.

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