Тестирование API: что проверять до запуска интеграции

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

Корректные запросы

Начинают с основных сценариев: создать, получить, изменить, удалить. Проверяют не только код ответа, но и содержимое: правильные поля, типы данных, форматы дат и сумм, кодировку текста на русском и узбекском. Особое внимание — к суммам: округление, разделитель дробной части, валюта. Проверьте также поведение с длинными именами, адресами на узбекском с апострофами и буквами o‘ и g‘: такие символы нередко ломают кодировку или поиск.

Ошибочные запросы

• Отсутствуют обязательные поля
• Неверные типы данных: текст вместо числа
• Слишком длинные строки и спецсимволы
• Несуществующие идентификаторы
• Неверный формат запроса

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

Авторизация и права

Запрос без ключа, с неверным ключом, с истёкшим токеном, с ключом другого пользователя. Особенно важно проверить, что пользователь не может получить или изменить чужие данные, подставив другой идентификатор в запрос. Это одна из самых распространённых уязвимостей API.

Граничные значения

Ноль, отрицательные числа, очень большие суммы, пустые списки, даты на границе периодов, последний день месяца, смена года. Ошибки чаще всего прячутся именно на границах.

Повторы и идемпотентность

В сетях запросы теряются и повторяются. Если клиент не получил ответ на запрос создания заказа и отправил его снова, не должно появиться два заказа. Для этого используют ключи идемпотентности или проверку уникальности. Тестируйте повторную отправку одного и того же запроса, особенно для платежей.

Ошибки внешней стороны

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

Нагрузка

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

Инструменты

Для ручной проверки используют Postman, Insomnia, утилиту curl. Для автоматических тестов — тестовые фреймворки языка разработки. Контрактные тесты проверяют, что API соответствует описанию в документации, например в спецификации OpenAPI. Нагрузочные тесты выполняют специализированными инструментами.

Автоматизация

Тесты API стоит запускать автоматически при каждом изменении кода. Тогда разработчик сразу видит, что его правка сломала существующее поведение, до того как изменение попадёт к пользователям. Набор тестов — это ещё и живая документация: по нему видно, как API должен себя вести.

Тестовая среда

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