Редакция Romanov Lab · Опубликовано
Успешный запрос из ручного клиента доказывает только то, что один набор данных однажды получил ответ. Приёмка интеграции должна подтвердить больше: правильные объекты изменены, посторонние не затронуты, повтор не удваивает действие, а после сбоя можно выяснить результат. Для этого нужен набор проверяемых сценариев, привязанный к реальному процессу.
Начните с границы ответственности
Запишите, что делает ваш компонент и что гарантирует внешний сервис. Например, магазин отправляет новый заказ в систему исполнения, получает её идентификатор и затем принимает статусы. В тестах отдельно проверяют отправку, сохранение связи, обработку ответов и входящий поток. Один общий пункт «интеграция работает» не позволяет понять, что именно сломалось.
Зафиксируйте версию API, используемые операции, разрешения, лимиты и схему данных. OpenAPI позволяет формально описывать интерфейс и использовать описание в инструментах проверки. Но совпадение JSON со схемой ещё не доказывает верную бизнес-логику: заказ на другой склад может быть совершенно корректным JSON.
Подготовьте изолированные данные и среду
Используйте отдельные тестовые сущности и предусмотренную провайдером среду. Идентификаторы, учётные данные и адреса тестового контура не должны смешиваться с рабочими. Перед прогоном проверяют не только адрес API, но и аккаунт, режим ключа и доступность связанных сервисов.
Не копируйте рабочую базу с персональными данными просто ради удобства. Обычно достаточно искусственного набора: обычный заказ, отсутствующий вариант, длинное название, дробное количество в разрешённой единице, отменённая запись. Если для воспроизведения нужны реальные сведения, состав и доступ ограничивают отдельно.
Платёжные проверки выполняют по официальным тестовым сценариям провайдера; Stripe, например, предоставляет тестовые средства для имитации разных результатов. Не используйте реальные платёжные реквизиты в автоматических тестах и не выполняйте рабочие списания ради проверки маршрута. Успех песочницы также не подтверждает все настройки рабочей среды.
Проверьте контракт на краях
Для каждого поля нужны обычное значение, граница допустимого и недопустимый вариант. Различайте отсутствие поля, null, пустую строку и ноль. Уточните, какие неизвестные поля можно игнорировать, а какие должны остановить обработку. При появлении неизвестного статуса нельзя выбирать ближайший знакомый только ради прохождения теста.
- Обязательный идентификатор отсутствует или имеет неверный тип.
- Название содержит кириллицу, кавычки и перенос.
- Количество выходит за допустимый диапазон.
- Валюта или единица измерения не поддерживается.
- Ответ содержит дополнительные поля.
- Внешний сервис вернул структурированный отказ вместо ожидаемого объекта.
Проверяйте и исходящий запрос, и интерпретацию ответа. Иногда интеграция отправляет данные правильно, но теряет ведущие нули в полученном идентификаторе или читает цену не из того поля.
Учебная матрица одной операции
Пусть операция создаёт тестовый заказ T-31 во внешней системе. Для каждого сценария записывают начальные условия, искусственный сбой и ожидаемый результат в обеих системах. В примере ниже нет готовых endpoint: это план испытаний, который связывают с документированными операциями выбранного сервиса.
- Обычный успех. Создан один внешний заказ, его идентификатор сохранён у T-31.
- Ответ потерян после создания. Локальная система показывает неизвестный результат и выясняет судьбу той же операции по поддерживаемому контракту.
- Повтор с тем же намерением. Не появляется второй заказ; если провайдер не поддерживает такую гарантию, фиксируется ограничение и безопасный порядок сверки.
- Неверные данные. Ошибка остаётся доступной для исправления и не попадает в бесконечный повтор.
- Входящий статус пришёл раньше сохранения связи. Событие не теряется и получает предусмотренную обработку после появления зависимости.
- Сбой локального обработчика. После восстановления можно продолжить с сохранённого состояния.
Ключевой результат — число и состояние созданных объектов. Проверка только HTTP-кода пропустит дубли и неверные связи.
Испытайте права отдельно от доступности
Действующий ключ может иметь слишком широкие права или работать не с тем аккаунтом. Проверьте минимально необходимые операции, отказ при обращении к чужому объекту и невозможность изменить поля, которыми интеграция не должна управлять. Рекомендации OWASP для REST API подчёркивают важность контроля доступа и проверки входных данных.
Секреты не должны появляться в тестовых отчётах, URL, скриншотах или сообщениях об ошибке. Подмена идентификатора объекта полезнее как проверка авторизации, чем обычный тест «ключ неверный». Последний проверяет вход в систему, но не разграничение действий внутри неё.
Проверьте задержки и восстановление нагрузки
Воспроизведите медленный ответ, ограничение частоты запросов, временный отказ и недоступность сети. Ожидаемое поведение определяется контрактом сервиса: когда повторять, когда ждать и когда передавать проблему человеку. Не превращайте любой ответ, включая ошибку данных, в одинаковый автоматический повтор.
После восстановления проверьте накопившуюся очередь. Она не должна одновременно отправить весь хвост и снова перегрузить получателя. Пользовательский интерфейс при этом различает «ожидает обработки», «отклонено» и «результат пока неизвестен». У каждого незавершённого объекта должна быть доступная техническая причина.
Заглушка и песочница отвечают на разные вопросы
Заглушка удобна для редких ошибок и точного воспроизведения потери ответа. Она проверяет вашу реакцию на заданный сценарий. Песочница проверяет совместимость с реальной реализацией провайдера. Нужны обе: заглушка может повторять неверное предположение разработчика, а песочница может не воспроизводить нужную гонку по требованию.
Сверяйте сохранённые примеры ответов с актуальным контрактом. Изменение версии API должно запускать регрессию, особенно для необязательных полей, перечислений статусов и ошибок. Реальный внешний ответ нельзя автоматически считать безопасным HTML для вставки в админку.
Соберите доказательства приёмки
Для каждого сценария сохраните безопасный идентификатор прогона, ожидаемый результат, фактическое состояние обеих сторон и вывод. Отдельно перечислите ограничения, которые не удалось воспроизвести. «Не проверено» полезнее зелёной галочки без доказательства.
Перед включением рабочей интеграции подготовьте контрольные чтения, способ остановить новый поток и порядок сверки незавершённых операций. Рабочие финансовые, удаляющие и другие значимые действия требуют собственного согласованного запуска. Тестовый прогон не является разрешением выполнять их автоматически.
Интеграцию можно принимать, когда известны нормальный путь, границы отказа и восстановление. Главный вопрос звучит так: если связь оборвётся в любой момент, сможет ли команда установить, что произошло, и закончить работу без лишнего действия?
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
