Писали ли интеграционные тесты в Python

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

Отличаете ли вы интеграционный тест от юнита и умеете ли поднимать зависимости так, чтобы прогон был повторяемым. Заодно смотрят, кто в команде чинит красный CI: вы или привычка перезапустить сборку, потому что «тесты опять моргнули».

Как отвечать

Интеграционный тест проверяет ваш код вместе с настоящей зависимостью: базой, брокером, соседним сервисом. Что стоит назвать:

• pytest и фикстуры разного уровня: контейнер поднимается на сессию, данные готовятся на каждый тест;
• testcontainers или compose для базы и брокера, готовность проверяется healthcheck, а не паузой;
• тестовый клиент фреймворка для своих ручек, httpx или requests для внешнего HTTP;
• изоляция данных: тест целиком в транзакции с откатом в фикстуре либо уникальные ключи;
• отдельная маркировка, чтобы быстрый прогон не требовал поднятой базы.

Полезно проговорить, где вы ставите границу: внешний платный сервис заменяется заглушкой на уровне HTTP, а своя база поднимается настоящая, потому что проверить хочется именно её диалект и накатанные миграции.

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

Называют интеграционным тест, в котором замокано всё, включая базу. Проверяется тогда только собственный код, а несовпадение типа колонки или забытая миграция проходят мимо и всплывают на стенде.

Тесты завязаны на состояние общей базы: первый оставил строки, второй падает, а по отдельности оба проходят. Лечится откатом транзакции или своими данными на каждый тест, а не договорённостью запускать их в нужном порядке.

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