Что такое интеграционное тестирование?

Question

Что такое интеграционное тестирование?

Тип вопроса: Основы тестирования Вероятность: 24% Категория: AQA / Automation

Ответ

Интеграционное тестирование — это уровень тестирования, на котором проверяется взаимодействие и корректность обмена данными между интегрированными модулями, компонентами или системами. Его цель — выявить дефекты на стыках модулей, в интерфейсах, API, контрактах и работе с общими ресурсами (базами данных, очередями, кешем).

Пример теста на Python (с использованием pytest):

# Тест интеграции сервиса заказов с сервисом оплаты и БД
def test_order_placement_integration(order_service, payment_gateway_mock, db_session):
    # 1. Arrange: Создаём тестовые данные в БД
    test_user = db_session.add(User(name='Ivan'))
    test_product = db_session.add(Product(price=100))

    # 2. Act: Вызываем метод сервиса заказов, который внутри:
    #    - обратится к БД (модуль доступа к данным)
    #    - вызовет мок платежного шлюза (внешний сервис)
    #    - обновит статус заказа
    new_order = order_service.place_order(user_id=test_user.id, product_id=test_product.id)

    # 3. Assert: Проверяем интеграцию всех компонентов
    assert new_order.status == 'PAID'
    assert payment_gateway_mock.was_called_with(amount=100)
    # Проверяем, что заказ действительно сохранён в БД
    order_in_db = db_session.get(Order, new_order.id)
    assert order_in_db is not None

Ключевые аспекты для QA:

Расположение в пирамиде тестирования: Следует после модульного тестирования и перед системным (end-to-end).
Подходы: «Снизу вверх» (от низкоуровневых модулей к UI), «сверху вниз» (от UI к низкоуровневым) или «большой взрыв» (всё сразу).
Основные объекты проверки: Передача данных, обработка ошибок, корректность ответов/исключений, состояние общих ресурсов после взаимодействия.
Инструменты: Часто требуются моки и стабы для изоляции тестируемого контура от внешних нестабильных или медленных зависимостей.

Ответ 18+ 🔞

А, интеграционное тестирование! Ну это, блядь, тот самый момент, когда отдельные модули, которые вроде бы сами по себе работают как часы, начинают общаться друг с другом. И тут-то, ёпта, и начинается настоящий цирк. Представь: один модуль кричит «дай!», другой мычит «на!», а третий вообще молча в сраку пинает. Вот чтобы этого не было, и нужны эти тесты.

По сути, это проверка не самих функций, а стыков между ними. API, базы данных, очереди сообщений — вся эта, блядь, инфраструктура, через которую они переписываются. Цель — поймать косяки там, где один кусок кода передаёт другому какую-то хуйню вместо данных, или когда оба думают, что обращаются к одному и тому же, а на деле — к разным вещам.

Вот смотри на этот пример кода (его не трогаем, он святой):

def test_order_placement_integration(order_service, payment_gateway_mock, db_session):
    test_user = db_session.add(User(name='Ivan'))
    test_product = db_session.add(Product(price=100))

    new_order = order_service.place_order(user_id=test_user.id, product_id=test_product.id)

    assert new_order.status == 'PAID'
    assert payment_gateway_mock.was_called_with(amount=100)
    order_in_db = db_session.get(Order, new_order.id)
    assert order_in_db is not None

Видишь, что здесь происходит? Это же чистая интеграция, ядрёна вошь! Мы не тестируем, как order_service там внутри циклы крутит. Мы проверяем цепочку: БД -> Сервис -> Внешний платёжный шлюз -> снова БД. Упало что-то на любом этапе — тест провален. Вот это и есть суть.

На что смотреть, если ты тестировщик, а не просто мартышлюшка с клавиатурой:

Место в пищевой цепочке: Это после unit-тестов, но до этих жирных и медленных end-to-end проверок. Золотая середина, блядь.
Как подходить: Можно собирать систему снизу вверх, как конструктор. Можно сверху вниз — от самого главного интерфейса вглубь. А можно по-русски — «большой взрыв»: собрать всё в кучу, запустить и охуеть от количества ошибок. Последний способ, конечно, для мазохистов.
Что ловить: Всё, что на стыке. Правильно ли данные передались? А если внешний сервис ответил ошибкой — наше приложение не сдохло, а красиво ругнулось? Состояние базы данных после всех операций не превратилось в кашу? Вот это всё.
Чем работать: Без моков и стабов тут вообще никуда. Потому что ждать ответа от реального платёжного гейта, который тупит, или от сервиса погоды, который сегодня не работает — это, прости, доверия ебать ноль. Подменяем их заглушками, которые ведут себя предсказуемо, и тестируем именно нашу логику взаимодействия.

Короче, смысл в том, чтобы убедиться, что все эти умные модули, когда их собирают вместе, работают как одна команда, а не как гомосеки налетели и начали выяснять, кто тут главный.