Какой стиль тестирования предпочитаешь?

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

Есть ли у вас осознанный подход к тестам или вы пишете их «чтобы было покрытие». Интервьюер хочет услышать, как вы решаете, что проверять юнит-тестом, что интеграционным и где заканчиваются моки. Следом часто спрашивают, практикуете ли вы TDD и как тестируете код, который ходит в базу или во внешний API.

Как отвечать

Ответ строится на вашем реальном подходе, но опирается на известные понятия:

• пирамида или «трофей»: много быстрых юнит-тестов на бизнес-логику и меньше, но обязательных интеграционных на стыки с базой, брокером и HTTP;
• школы: классическая (детройтская) проверяет поведение через реальные объекты и мокает только внешние границы, лондонская мокает всех соседей. Для сервисов на Python практичнее первая;
• инструменты: pytest с фикстурами и @pytest.mark.parametrize, unittest.mock или pytest-mock, respx или responses для внешнего HTTP, настоящий PostgreSQL в Testcontainers вместо моков ORM, Hypothesis для property-based тестов, pytest-cov для покрытия;
• TDD: честно скажите, где применяете. Часто это логика с понятным контрактом и исправление багов: сначала падающий тест, потом фикс.

Затем пример из своей практики: какой баг поймал интеграционный тест, который пропустили бы юнит-тесты на моках. Цифры, если приводите, только свои. Если строгого подхода в команде не было, так и скажите и объясните, как выстроили бы его сейчас.

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

Мокают всё подряд, включая собственную ORM. Такие тесты проверяют моки, проходят при сломанном SQL и ломаются при любом рефакторинге.

Делают покрытие целью. 100% строк не гарантируют проверку граничных случаев, а погоня за цифрой рождает тесты без единого осмысленного assert.

Путаются в mock.patch: патчат имя там, где объект определён, а не там, где он импортирован и используется, и тест молча работает с настоящим объектом.