Можешь привести пример тестовых сценариев, которые ты выполнял в процессе интеграционного тестирования?

Что хотят услышать интервьюеры:

Интервьюеру важно понять, что есть практический опыт интеграционного тестирования и понимание, как проверять взаимодействие между системами. Хорошо, если пример показывает не только позитивный сценарий, но и обработку ошибок, задержек и некорректных данных. Также ценится умение проверять контракты, очереди, API и влияние одной системы на другую.

Определение:

Интеграционное тестирование — это проверка того, как разные компоненты или сервисы работают вместе: сервисы, API, базы данных, очереди, внешние системы. В отличие от модульного тестирования, здесь проверяется не отдельная функция, а взаимодействие между частями системы и корректность передачи данных между ними.

Пример использования:

Например, при тестировании оформления заказа можно проверить цепочку: фронт отправляет запрос в backend, backend создает заказ в БД, затем публикует событие в очередь, а сервис доставки получает его и меняет статус заказа.

Сценарий: оформление заказа

1. Отправить запрос POST /orders с валидными данными.
2. Проверить, что заказ создан в базе.
3. Убедиться, что в ответе вернулся корректный orderId.
4. Проверить, что сообщение ушло в очередь на обработку доставки.
5. Проверить, что статус заказа изменился на "created" или "processing".
6. Повторить сценарий с невалидными данными и убедиться, что заказ не создается.

Пояснение кода:

Код не требуется. В этом примере сценарий можно разложить по шагам: сначала формируется входной запрос, затем проверяется ответ API, после этого — запись в БД и факт публикации события. Отдельно важно проверить негативный путь: например, если не хватает обязательного поля, система должна вернуть ошибку и не создавать заказ. Такой подход показывает, что проверяется не только один сервис, а вся цепочка интеграции.

Ключевые моменты:

• Лучше приводить конкретный бизнес-сценарий, а не абстрактный пример.
• Важно показывать проверку нескольких уровней: API, БД, очередь, внешний сервис.
• Негативные сценарии не менее важны, чем позитивные.
• Хорошо упомянуть проверку контрактов, статусов и целостности данных.
• Если был опыт с моками или стендами, это стоит назвать как часть подготовки окружения.
• Полезно показать, что после действия в одной системе проверялся эффект в другой.