Интеграционное Тестирование — это тип тестирования, при котором отдельные программные модули (компоненты) объединяются и тестируются как единая группа

Ключевая Цель

Выявить дефекты, возникающие на “стыках” (интерфейсах) между различными частями системы.

Даже если два модуля идеально работают по отдельности, проблемы возникают при их соединении. Например, один модуль отправляет данные в формате A, а второй ожидает их в формате B.

Что конкретно проверяется

Тестирование фокусируется на потоках данных между модулями.

  • Взаимодействие “Frontend ↔ Backend”:

    • Проверка: Фронтенд отправляет HTTP-запрос к API бэкенда.

    • Тест: Бэкенд корректно получает запрос, обрабатывает его и возвращает JSON в ожидаемом фронтендом формате? Что, если бэкенд вернул ошибку 500 (Server Error)? Отобразит ли фронтенд “плашку” об ошибке?

  • Взаимодействие “Backend ↔ База Данных (БД)”:

    • Проверка: Бэкенд-сервис пытается записать данные в БД.

    • Тест: Данные корректно записались в нужные таблицы? Соблюдены ли ограничения БД? Корректно ли бэкенд читает эти данные обратно?

  • Взаимодействие “Backend ↔ Backend” (Микросервисы):

    • Проверка: Сервис A (например, “Сервис Заказов”) обращается к Сервису Б (например, “Сервис Склада”) по внутреннему API.

    • Тест: Проходит ли запрос? Что, если Сервис Б “упал” или отвечает слишком долго?

  • Взаимодействие “Система ↔ Внешний API”:

    • Проверка: Ваше приложение обращается к стороннему сервису (например, платежному шлюзу, службе доставки, API соцсетей).

    • Тест: Корректно ли вы отправляете ключ авторизации (API Key)? Правильно ли вы обрабатываете ответы от этого внешнего сервиса?

Заглушки и Моки

Часто для интеграционного теста (например, “Frontend ↔ Backend”) нам не нужен полностью рабочий компонент. Мы используем “заглушки” или “моки”.

  • Заглушка (Stub): Это простая реализация-заменитель, которая просто возвращает заранее заданный, “захардкоженный” ответ.

    • Пример: Мы тестируем Фронтенд. Вместо настоящего Бэкенда мы используем Mock-сервер, который на запрос GET /api/users всегда, не думая, возвращает готовый JSON [{"id": 1, "name": "Test"}].

Определение

Хардкод — это когда значение или правило “вшито” прямо в код (число, строка, условие) вместо того, чтобы брать его из настроек, данных или нормальной логики.

  • Мок (Mock): “Умная” заглушка. Это объект-заменитель, который не только возвращает ответы, но и “следит” за тем, как его использовали.

    • Пример: Мы тестируем “Сервис Заказов”. Мы “мокаем” (заменяем) “Сервис E-mail”. После выполнения теста мы проверяем у “мока”: “А правда, что тебя вызвали ровно 1 раз? А правда, что тебе передали e-mail user@test.com?“.

Среды (Стенды) для Интеграционного Тестирования

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

Чаще всего такие стенды называют INT (Integration) или TEST / QA. На этом окружении одновременно развернуты (запущены) и работают все необходимые для проверки взаимодействия сервисы:

  • Сам тестируемый сервис (или компонент);

  • Его базы данных (лежат тестовые пользователи, заказы и т.п.);

  • Брокеры сообщений (Системы, которые передают сообщения между сервисами. Грубо говоря, «общий ящик», куда один сервис кладёт сообщение, а другой забирает);

  • API-сервисы соседних систем, от которых он зависит (например, сервис корзины зависит от сервиса карточки товара);

  • Тестовые версии внешних интеграций (например, банковских шлюзов, служб доставки) или их «моки» (mocks) — эмуляторы, имитирующие их ответ.

Иерархия Окружений

Стандартная иерархия (логика) окружений в разработке обычно выглядит следующим образом:

  1. Локальный / DEV
    Среда на машине разработчика. Используется для написания кода и модульных (unit) тестов.

  2. Интеграционный / TEST / INT
    Специализированный стенд для проверки того, как модули и сервисы работают вместе (проведение интеграционного тестирования).

  3. STAGE / PRE-PROD (Препрод)
    Стенд, максимально идентичный производственной среде. Используется для финальной сквозной проверки, нагрузочного тестирования и регресса перед релизом.

  4. PROD (Production)
    “Боевая” среда, где работают реальные пользователи. На ней проводятся только эксплуатационные работы, но не тестирование.

Заключение

Что дальше?

➡️Погрузимся в регрессионное тестирование

НазадДалее