Что хотят услышать интервьюеры:

Да, интеграционные сценарии тестировались, чтобы проверить взаимодействие между сервисами, БД, очередями и внешними API. Обычно такие тесты нужны там, где unit-тестов недостаточно и важна проверка реального потока данных. Хорошо, если есть понимание границы между unit, integration и end-to-end тестами.

Определение:

Интеграционное тестирование проверяет, что несколько компонентов системы корректно работают вместе: например, код приложения, база данных, кэш, очередь сообщений или внешний сервис. В Python это часто означает тесты с поднятой тестовой БД, моками только внешних зависимостей и проверкой результата на уровне нескольких слоёв приложения.

Пример использования:

Например, в сервисе оформления заказа можно проверить сценарий: API получает запрос, сохраняет заказ в тестовую БД, отправляет событие в очередь и возвращает корректный ответ. Такой тест проверяет не только функцию, а весь рабочий путь между компонентами.

def test_create_order_integration(client, db_session, mock_queue):
    response = client.post("/orders", json={
        "user_id": 1,
        "items": [{"sku": "A1", "qty": 2}]
    })

    assert response.status_code == 201
    assert response.json()["status"] == "created"

    order = db_session.query(Order).filter_by(user_id=1).one()
    assert order.total_items == 2

    mock_queue.publish.assert_called_once()

Пояснение кода:

В примере тест вызывает HTTP-эндпоинт через тестовый клиент, как это делает реальный потребитель API. Затем проверяется, что заказ действительно сохранился в базе через db_session. После этого проверяется, что сообщение было отправлено во внешнюю систему, но сама очередь заменена тестовым мок-объектом mock_queue.

Если говорить о шаге за шагом, то сначала создаётся входной запрос, затем система обрабатывает его целиком, после чего проверяются побочные эффекты: ответ API, запись в БД и взаимодействие с внешней зависимостью. Это и есть типичный интеграционный сценарий.

Ключевые моменты:

Интеграционные тесты проверяют связку компонентов, а не одну функцию изолированно.
В таких тестах часто используют реальную тестовую БД и моки только для внешних систем.
Важно проверять не только статус ответа, но и побочные эффекты: запись в БД, события, вызовы API.
Интеграционные тесты медленнее unit-тестов, поэтому их обычно меньше и они покрывают самые важные сценарии.
Хороший ответ на собеседовании показывает понимание пирамиды тестирования и границ ответственности каждого типа тестов.

Проводил ли ты тестирование интеграционных сценариев в своих проектах?