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

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
Тело ответа отсутствует

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

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

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

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