API и интеграционное тестирование

Все темы QA

Что проверяет контрактное тестирование сервисов?

Контрактный тест проверяет, что провайдер понимает запросы потребителя и возвращает согласованные статусы, заголовки и схему данных. Потребитель публикует ожидания на конкретных примерах, провайдер проверяет их на своей реализации; версии контрактов позволяют решить, совместим ли релиз с используемыми клиентами. Такой тест быстро ловит несовместимое изменение границы сервиса, но не доказывает работу сети, инфраструктуры, общей базы сценария или взаимодействие всех реальных компонентов. Для этого нужны интеграционные и E2E-проверки. Контракт не должен фиксировать случайные детали ответа, которыми потребитель не пользуется.

Как тестировать обмен сообщениями через брокер?

Тест поднимает контролируемый брокер или изолированный namespace, отправляет сообщение и ждёт условие с конечным таймаутом, а не фиксированный sleep. Уникальные topic, queue или consumer group и correlation key защищают параллельные прогоны от чужих сообщений. Проверяют payload, headers, ключ маршрутизации, побочный бизнес-эффект, повторы и обработку невалидного сообщения. Отдельно моделируют недоступность потребителя и redelivery, если это часть контракта. После теста удаляют созданные данные и останавливают consumer. Успешный produce подтверждает приём брокером, но не обработку сообщения конечным сервисом.

Какие дефекты могут скрыть стабы?

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

Как встроить контрактные тесты в CI/CD?

Consumer в своём pipeline проверяет клиентский код и публикует версионированный контракт вместе с версией приложения и веткой. Pipeline провайдера загружает актуальные контракты и проверяет их на реальной реализации. Broker хранит результаты verification и матрицу совместимости. Перед deploy система спрашивает, совместима ли конкретная версия со всеми поддерживаемыми потребителями; отрицательный ответ блокирует выпуск или требует согласованной миграции. Нужны правила для feature branches, устаревших клиентов и удаления контрактов, иначе матрица быстро засоряется. Проверка должна выполняться до production, но её результат относится только к проверенным версиям.

Как ждать завершения асинхронной операции API?

После запуска операции клиент получает идентификатор и опрашивает status endpoint до терминального состояния. Ожидание ограничивают общим timeout, между запросами используют разумный interval или backoff с jitter и учитывают серверный Retry-After, если он есть. Проверка должна явно завершаться на succeeded, failed и других терминальных статусах, а не ждать только успеха. При timeout в отчёт сохраняют последний ответ, идентификатор операции и время. Фиксированный sleep делает тест медленным и нестабильным. Если система поддерживает callback или событие, его также ждут с дедлайном и correlation ID.

Как mock-сервером проверить HTTP-зависимость API?

Приложение направляют на WireMock или MockServer вместо реальной HTTP-зависимости. Для каждого сценария задают совпадение по методу, пути, заголовкам и телу, затем управляемый ответ: нужный статус, JSON, задержку, обрыв или невалидное тело. После вызова проверяют не только реакцию приложения, но и фактический исходящий запрос, включая авторизацию и correlation ID. Сценарии должны покрывать timeout, retry и отсутствие повтора для небезопасной операции. Такой тест проверяет HTTP-поведение клиента, но не совместимость с реальным сервисом, если stub не сверяется с контрактом.

Как тестировать 401 и 403 в защищённом API?

Проверяют запрос без учётных данных, с повреждённым, просроченным и предназначенным другой аудитории токеном. Для них обычно ожидают 401 Unauthorized и корректный WWW-Authenticate, если схема это предусматривает. Валидный субъект с недостаточными правами должен получить 403 Forbidden. Также проверяют доступ к чужому объекту: API не должно раскрывать его существование через текст, время или разные детали ответа; иногда контракт намеренно возвращает 404. Во всех случаях состояние не меняется, секреты и внутренние причины не попадают в тело или логи клиента, а аудит содержит безопасный идентификатор запроса.