Какие тесты ты пишешь: функциональные или юнит тесты?
Что проверяют
Правильный ответ почти всегда «и те и другие», поэтому интервьюер слушает другое: как вы решаете, что каким тестом покрыть, и чем пишете. Следом обычно спрашивают, как вы изолируете базу и внешние API в тестах.
Как отвечать
Коротко разведите понятия: юнит-тест проверяет функцию или класс в изоляции и работает миллисекунды, функциональный проверяет фичу целиком через внешний интерфейс, например HTTP-запрос к API с реальной базой. Между ними интеграционные тесты, и хорошо показать, что вы это различаете.
Дальше опирайтесь на свой проект:
- юнит-тесты на
pytest: бизнес-логика, валидация, расчёты. Фикстуры,@pytest.mark.parametrize, подмена зависимостей черезunittest.mockилиpytest-mock; - функциональные тесты API: в FastAPI через
TestClientилиhttpx.AsyncClient, в Django через тестовыйClientилиAPITestCaseиз DRF. Проверяете статус, тело ответа и то, что записалось в базу; - окружение: настоящий PostgreSQL в Testcontainers или отдельной тестовой базе, откат транзакции после каждого теста, фабрики данных через factory_boy, заморозка времени через
freezegunилиtime-machine; - UI-сценарии, если они на вас: Playwright для Python.
Покажите принцип распределения: логику с большим числом ветвлений дешевле покрыть юнит-тестами, а склейку слоёв, сериализацию и права доступа видно только в функциональных. Упомяните, что всё гоняется в CI и сколько идёт прогон.
Цифры берите свои: сколько тестов, какое покрытие по pytest-cov, какой баг поймали. Если функциональные тесты в команде писали тестировщики, так и скажите и объясните, как вы с ними делили зону ответственности.
Где спотыкаются
Называют юнит-тестом всё, что написано на pytest, включая тесты с живой базой. Инструмент не определяет уровень теста.
Мокают так много, что тест проверяет настройку моков, а не код. После рефакторинга такие тесты падают, хотя поведение не менялось.
Приводят круглые проценты про снижение числа багов, не зная, как их мерили. Первый же уточняющий вопрос такую цифру разбирает.