Проблема:
При изменении API (например, добавление нового поля
delivery_date или изменение структуры ошибок) клиентское приложение должно продолжать работать корректно. Модульные тесты проверяют отдельные функции изолированно и не выявят проблемы с форматом ответа от сервера. Системное тестирование проверяет систему в целом (сквозные сценарии), но оно дорогое и медленное. Приёмочное тестирование проводится с заказчиком и тоже не является первым шагом.Интеграционное тестирование проверяет взаимодействие между двумя компонентами (клиент ↔️ сервер). В данном случае оно идеально: вы поднимаете тестовый экземпляр бэкенда с новой версией API, отправляете запросы от клиента (или эмулируете их) и проверяете, что клиент правильно парсит ответы, обрабатывает ошибки, не падает при неожиданных данных. Интеграционные тесты дают быструю обратную связь без запуска всей системы.
Реальный пример:
В Uber при обновлении API для водительского приложения сначала запускают интеграционные тесты, чтобы убедиться, что новое поле
rating корректно отображается и не ломает старый код.Что должен зафиксировать аналитик:
«При изменении контракта API обязательно проводить интеграционное тестирование на тестовом стенде до выкатки в прод».
Вывод: Интеграционное тестирование – наиболее подходящий уровень для проверки совместимости клиента и сервера при изменении API, так как оно фокусируется на коммуникации без лишней сложности.