Разработка интеграций с внешней инфраструктурой (платежки, ID-провайдеры, SMS-шлюзы) всегда упирается в Sandboxes. И слепая вера в песочницу вендора ведет к инцидентам в продакшене и как выстроить надежный процесс тестирования.
⚪️Главный враг: дрейф песочницы
- Тестовые среды вендоров — это симуляции, но не дубликаты продакшена. Вендоры обновляют песочницы по остаточному принципу.
- В продакшене появляется новое поле или меняется структура токена, а в песочнице — часто нет (или не сразу). Логика rate limiting и специфические HTTP 4xx/5xx ошибки в песочнице часто вовсе не имплементированы.
- Как итог успешный деплой и сбой на реальном трафике из-за расхождения среды с продакшеном, возникшего еще пару месяцев назад.
⚪️ Что реально нужно тестировать
- Обработку nullable-полей, опциональных ключей и специфических типов.
- Проверку поведения системы при отваливающемся провайдере (таймауты, специфические коды ответов вроде 402, асинхронные вебхуки невпопад). Песочницы провайдеров чаще всего поддерживают только happy path.
- State Management: побочные эффекты тестирования (записи, аудит-логи) остаются в песочнице провайдера. Внезапные плавающие сбои в CI часто вызваны грязным состоянием тестовой среды вендора.
⚪️Рабочая стратегия: Record & Replay вместо прямой зависимости
Чтобы не зависеть от изменения чужих сред, инженерные команды переходят на локально контролируемый baseline:
- Запись и воспроизведение трафика: перехват реальных HTTP-ответов (через Keploy, Hoverfly, WireMock в режиме записи) и сохранение их в качестве локальных фикстур.
- Версионирование фикстур в Git: обновление фикстур становится осознанным коммитом в репозиторий, а не фоновым изменением на стороне вендора.
- Explicit Fault Injection: явное создание фикстур под таймауты, битые JSON и специфические 5xx-ошибки.
⚪️Почему Contract Testing (Pact) не спасает на 100%
Contract testing проверяет схему (структуру запроса и ответа). Но он не ловит поведенческие изменения под капотом. Схема может оставаться валидной, но провайдер изменил формулу расчета комиссии или сделал синхронный вебхук асинхронным. Схема совпала, логика сломалась.
⚪️ Плата за надежность: Обслуживание фикстур
Главный подводный камень собственного Record & Replay — протухание фикстур. В качестве решения процесс обновления фикстур должен быть явно закреплен за командой (explicit ownership) и входить в техдолг/бэклог при каждом релизе изменений в API провайдера.
Песочница провайдера подходит для первичного exploratory-тестирования и smoke-тестов. Регрессионный пайплайн должен опираться на локально зафиксированные, версионируемые фикстуры реальных ответов.
@DevOpsKaz 😛