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

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

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

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

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

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

• круглые конфеты «Одобрено»
• некруглые конфеты «Не одобрено»

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

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

При положительном сценарии и успешной интеграции двух компонентов мы ожидаем, что на HTTP-запрос клиента сервер вернет HTTP-ответ с кодом 200 OK. Но бывают и другие коды ответа, приведенные в таблице.

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

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

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