Интеграционное тестирование

Integration Testing

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

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

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

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

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

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

Браузер посылает запрос на добавление новой печеньки на склад
Склад посылает запрос в Сервис качества, чтобы проверить печеньку на соответствие уровню качества

Сервис качества возвращает складу ответ «Одобрено», либо «Не одобрено» в зависимости от результата проверки
если сервис качества вернул ответ «Одобрено», склад сохраняет печеньку и отвечает браузеру OK
если сервис качества вернула ответ «Не одобрено», склад не сохраняет печеньку и отвечает браузеру Bad Request

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

Как выяснилось, компонент Сервис качества ещё не готов к проведению тестирования. Мы не хотим ожидать окончания его разработки и готовы проверить взаимодействие Браузера и Склада, используем заглушку!

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

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

круглые печеньки «Одобрено»
некруглые печеньки «Не одобрено»

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

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

печенька прошла проверку качества и должна быть добавлена на Склад,
Браузер должен получить ответ OK
печенька не прошла проверку качества и не должна быть добавлена на Склад,
Браузер должен получить ответ Bad Request

HTTP-коды ответа

При положительном сценарии и успешной интеграции двух компонентов мы ожидаем, что на 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.

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

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

Эндпоинт:

Выберите метод HTTP:

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

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

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

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

На чьей стороне возникла ошибка?

На стороне сервера

На стороне клиента

Код ответа не сигнализирует об ошибке