Как проводить интеграционное тестирование, если внешняя система недоступна или не может быть развернута локально?

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

1. Использование mock

Определение:
Mock — это объект, который имитирует поведение реальной зависимости и возвращает заранее заданные ответы.

Пример:

from unittest.mock import patch

@patch("requests.get")
def test_api(mock_get):
    mock_get.return_value.status_code = 200
    # вызов функции, использующей requests.get

Плюсы:

1. Быстро

2. Стабильно

3. Не зависит от сети

Минусы:

1. Не проверяет реальную интеграцию полностью

2. Использование stub или fake

Stub — более простой объект, который возвращает фиксированные данные.

Пример:

• локальный HTTP-сервер с подготовленными ответами

• JSON-файлы с примерами ответов

Это полезно, когда нужно проверить обработку реальных структур данных.

3. Тестовые контейнеры

Если сервис можно поднять локально:

1. Используют Docker

2. Поднимают тестовую БД или брокер

Это ближе к реальной интеграции.

4. Sandbox-окружения

Некоторые внешние API предоставляют тестовые среды:

• платежные системы

• облачные сервисы

Это позволяет тестировать реальные сценарии без риска.

5. Комбинированный подход

На практике:

1. Unit-тесты используют mock

2. Интеграционные тесты — реальные сервисы

3. E2E — полный сценарий

Вывод

Если внешняя система недоступна, используют mock, stub или тестовые контейнеры. Такой подход делает тесты воспроизводимыми и контролируемыми.