Основная цель интеграционного тестирования — проверить успешность взаимодействия компонентов друг с другом. Оно выполняется на более высоком уровне, чем модульное тестирование, при котором отдельные части системы уже были протестированы на корректность функционирования в изоляции.
При проведении интеграционного тестирования могут тестироваться как два так и более компонентов.
В качестве примера для проведения интеграционного тестирования возьмём систему, состоящую из трёх компонентов:
Как выяснилось, компонент Проверка качества ещё не готов к проведению тестирования. Мы не хотим ожидать окончания его разработки и готовы проверить взаимодействие компонента 1 с компонентом 2, используем заглушку!
Сервисы-заглушки могут писать как разработчики, так и тестировщики, используя различные инструменты.
Заглушка сымитирует работу компонента 3.
Нам известно, что Склад конфет ожидает два варианта ответа: «Одобрено» либо «Не одобрено». Создадим примитивный сервис-заглушку, способный возвращать эти два ответа на основании упрощенной логики, например:
Интеграционное тестирование взаимодействия компонента 1 с компонентом 2 (вместо компонента 3 используется заглушка) сводится к проверке двух основных сценариев:
При положительном сценарии и успешной интеграции двух компонентов мы ожидаем, что на HTTP-запрос клиента сервер вернет HTTP-ответ с кодом 200 OK. Но бывают и другие коды ответа, приведенные в таблице.
| Код | Описание | Пример |
|---|---|---|
| 1xx | Информационные | 102 — запрос обрабатывается (Processing) |
| 2xx | Успешно | 200 — запрос выполнен успешно (OK) |
| 3xx | Перенаправление | 301 — ресурс по данному адресу был перемещен (Moved Permanently) |
| 4xx | Ошибка клиента |
400 — запрос клиента содержит ошибку (Bad Request) 403 — у клиента нет прав для доступа к данному ресурсу (Forbidden) |
| 5xx | Ошибка сервера | 500 — во время обработки запроса на сервере произошла ошибка (Internal Server Error) |
Тестируемая система включает в себя два компонента: клиентское и серверное приложение.
Фронтэнд-разработчик создал клиентскую часть — «Форму для отправки HTTP-запроса», а бэкенд-разработчик написал логику обработки запроса на сервере. Они договорились об условиях успешного обмена данными (см. API).
Выступите в роли клиента, проверьте успешность взаимодействия компонентов.
Договорённость по формату запроса:
Ожидаемый при успешной интеграции ответ:
Уровень повышен!