Интеграционное тестирование (Integration Testing)

handshake

Основная цель интеграционного тестирования — проверить успешность взаимодействия компонентов друг с другом. Оно выполняется на более высоком уровне, чем модульное тестирование, при котором отдельные части системы уже были протестированы на корректность функционирования в изоляции.

При проведении интеграционного тестирования могут тестироваться как два так и более компонентов.


Пример интеграционного тестирования

В качестве примера для проведения интеграционного тестирования возьмём систему, состоящую из трёх компонентов:

  • браузерное приложение для добавления конфет на склад — компонент 1
  • сервис, хранящий информацию о конфетах — компонент 2
  • сервис, проводящий контроль качества конфет — компонент 3

Сценарий взаимодействия компонентов

  1. компонент 1 посылает запрос на добавление новой конфеты в компонент 2
  2. компонент 2 посылает запрос в компонент 3, чтобы проверить качество конфеты
  3. если конфета соответствует требованиям качества компонент 3 возвращает компоненту 2 ответ «Одобрено»
    иначе компонент 3 возвращает компоненту 2 ответ «Не одобрено»
  4. если компонент 3 вернул ответ «Одобрено», компонент 2 сохраняет конфету и отвечает компоненту 1 OK
    если компонент 3 вернул ответ «Не одобрено», компонент 2 не сохраняет конфету и отвечает компоненту 1 Bad Request
three-components

Использование заглушек

Как выяснилось, компонент 3, проводящий контроль качества новых конфет, ещё не готов к проведению тестирования. Но мы не хотим ожидать окончания его разработки и готовы проверить взаимодействие компонента 1 с компонентом 2. Для такого случая были придуманы заглушки.

При помощи заглушки мы можем сымитировать работу компонента 3, опустив сложную логику проверки качества конфеты. Нам известно, что компонент 2 ожидает всего два варианта ответа: «Одобрено» либо «Не одобрено».

То есть нам нужно создать примитивный сервис-заглушку, способную возвращать эти два ответа на основании упрощенной логики, например, все квадратные конфеты будут получать статус «Не одобрено».

Такие сервисы-заглушки могут писать как разработчики, так и тестировщики, используя различные инструменты.

component-mock

Проведение тестирования

Интеграционное тестирование взаимодействия компонента 1 с компонентом 2 (вместо компонента 3 использовалась заглушка) сводится к проверке двух основных сценариев взаимодействия:

  1. правильная конфета прошла проверку качества в компоненте 3 и была добавлена на склад в компоненте 2,
    компонент 1 получил ответ OK
  2. неправильная конфета не прошла проверку качества в компоненте 3 и не была добавлена на склад в компоненте 2,
    компонент 1 получил ответ Bad Request

Задача

Тестируемая система включает в себя два компонента: клиентское и серверное приложение.

Фронтэнд-разработчик создал клиентскую часть — «Форму для отправки HTTP-запроса», а бэкенд-разработчик написал логику обработки запроса на сервере. Они договорились об условиях успешного обмена данными (см. API).

Выступите в роли клиента, проверьте успешность взаимодействия компонентов.


Форма для отправки HTTP-запроса

Договорённость по формату запроса:

  • Эндпоинт /hello-server
  • HTTP метод, соответствующий получению данных с сервера

Ожидаемый при успешной интеграции ответ:

  • Статус ответа с кодом 200
  • Тело ответа отсутствует

Информация о значении кодов ответа.

Код Описание Пример
1xx Информационные 102 - запрос обрабатывается (Processing)
2xx Успешно 200 - запрос выполнен успешно (OK)
3xx Перенаправление 301 - ресурс по данному адресу был перемещен (Moved Permanently)
4xx Ошибка клиента 400 - запрос клиента содержит ошибку (Bad Request)
403 - у клиента нет прав для доступа к данному ресурсу (Forbidden)
5xx Ошибка сервера 500 - во время обработки запроса на сервере произошла ошибка (Internal Server Error)