--- title: API и интеграционное тестирование questionDates: q-transfer-0371: '2026-10-01' q-transfer-0372: '2026-10-01' q-transfer-0373: '2026-10-01' q-transfer-0374: '2026-10-01' q-transfer-0375: '2026-10-01' q-transfer-0389: '2026-10-01' q-transfer-0390: '2026-10-01' seo: description: >- Тема «API и интеграционное тестирование» для собеседования QA. Что проверяет контрактное тестирование сервисов? Как тестировать обмен сообщениями через брокер? title: API и интеграционное тестирование — QA --- [Все темы QA](/prep/qa) ## Что проверяет контрактное тестирование сервисов? [#q-transfer-0371] Контрактный тест проверяет, что провайдер понимает запросы потребителя и возвращает согласованные статусы, заголовки и схему данных. Потребитель публикует ожидания на конкретных примерах, провайдер проверяет их на своей реализации; версии контрактов позволяют решить, совместим ли релиз с используемыми клиентами. Такой тест быстро ловит несовместимое изменение границы сервиса, но не доказывает работу сети, инфраструктуры, общей базы сценария или взаимодействие всех реальных компонентов. Для этого нужны интеграционные и E2E-проверки. Контракт не должен фиксировать случайные детали ответа, которыми потребитель не пользуется. :::note[Ссылки для изучения] 1. [Контрактные тесты с Pact: consumer, provider и границы проверки](https://habr.com/ru/companies/kuper/articles/845964/) ::: --- ## Как тестировать обмен сообщениями через брокер? [#q-transfer-0372] Тест поднимает контролируемый брокер или изолированный namespace, отправляет сообщение и ждёт условие с конечным таймаутом, а не фиксированный `sleep`. Уникальные topic, queue или consumer group и correlation key защищают параллельные прогоны от чужих сообщений. Проверяют payload, headers, ключ маршрутизации, побочный бизнес-эффект, повторы и обработку невалидного сообщения. Отдельно моделируют недоступность потребителя и redelivery, если это часть контракта. После теста удаляют созданные данные и останавливают consumer. Успешный `produce` подтверждает приём брокером, но не обработку сообщения конечным сервисом. :::note[Ссылки для изучения] 1. [Тест обмена через Kafka: ожидание бизнес-эффекта с Awaitility — кейс Циан](https://habr.com/ru/companies/cian/articles/802673/) ::: --- ## Какие дефекты могут скрыть стабы? [#q-transfer-0373] Стаб скрывает дефект, если отвечает не так, как production: принимает устаревшую схему, пропускает обязательный заголовок, возвращает только успешный статус или упрощает задержки и ошибки. Он также может не воспроизвести правила авторизации, кодировку, пагинацию и ограничения размера. Чтобы снизить риск, заглушку генерируют или проверяют по версионируемому контракту, добавляют негативные ответы и периодически запускают интеграционный тест с реальным сервисом. Чем больше собственной логики в стабе, тем выше шанс тестировать модель, а не систему. Стаб нужен для управляемости, но не является доказательством совместимости. :::note[Ссылки для изучения] 1. [Как согласовать consumer mock с реальным сервисом: Pact verification](https://habr.com/ru/companies/kuper/articles/845964/) ::: --- ## Как встроить контрактные тесты в CI/CD? [#q-transfer-0374] Consumer в своём pipeline проверяет клиентский код и публикует версионированный контракт вместе с версией приложения и веткой. Pipeline провайдера загружает актуальные контракты и проверяет их на реальной реализации. Broker хранит результаты verification и матрицу совместимости. Перед deploy система спрашивает, совместима ли конкретная версия со всеми поддерживаемыми потребителями; отрицательный ответ блокирует выпуск или требует согласованной миграции. Нужны правила для feature branches, устаревших клиентов и удаления контрактов, иначе матрица быстро засоряется. Проверка должна выполняться до production, но её результат относится только к проверенным версиям. :::note[Ссылки для изучения] 1. [Pact в CI/CD: публикация контрактов, verification и can-i-deploy](https://habr.com/ru/companies/kuper/articles/845964/) ::: --- ## Как ждать завершения асинхронной операции API? [#q-transfer-0375] После запуска операции клиент получает идентификатор и опрашивает status endpoint до терминального состояния. Ожидание ограничивают общим timeout, между запросами используют разумный interval или backoff с jitter и учитывают серверный `Retry-After`, если он есть. Проверка должна явно завершаться на `succeeded`, `failed` и других терминальных статусах, а не ждать только успеха. При timeout в отчёт сохраняют последний ответ, идентификатор операции и время. Фиксированный `sleep` делает тест медленным и нестабильным. Если система поддерживает callback или событие, его также ждут с дедлайном и correlation ID. :::note[Ссылки для изучения] 1. [Опрос статуса асинхронной операции: Location, Retry-After и конечные состояния — Microsoft](https://learn.microsoft.com/ru-ru/azure/architecture/patterns/asynchronous-request-reply) ::: --- ## Как mock-сервером проверить HTTP-зависимость API? [#q-transfer-0389] Приложение направляют на WireMock или MockServer вместо реальной HTTP-зависимости. Для каждого сценария задают совпадение по методу, пути, заголовкам и телу, затем управляемый ответ: нужный статус, JSON, задержку, обрыв или невалидное тело. После вызова проверяют не только реакцию приложения, но и фактический исходящий запрос, включая авторизацию и correlation ID. Сценарии должны покрывать timeout, retry и отсутствие повтора для небезопасной операции. Такой тест проверяет HTTP-поведение клиента, но не совместимость с реальным сервисом, если stub не сверяется с контрактом. :::note[Ссылки для изучения] 1. [HTTP-заглушка и проверка исходящих запросов с WireMock: кейс Яндекса](https://habr.com/ru/companies/yandex/articles/228691/) ::: --- ## Как тестировать 401 и 403 в защищённом API? [#q-transfer-0390] Проверяют запрос без учётных данных, с повреждённым, просроченным и предназначенным другой аудитории токеном. Для них обычно ожидают `401 Unauthorized` и корректный `WWW-Authenticate`, если схема это предусматривает. Валидный субъект с недостаточными правами должен получить `403 Forbidden`. Также проверяют доступ к чужому объекту: API не должно раскрывать его существование через текст, время или разные детали ответа; иногда контракт намеренно возвращает `404`. Во всех случаях состояние не меняется, секреты и внутренние причины не попадают в тело или логи клиента, а аудит содержит безопасный идентификатор запроса. :::note[Ссылки для изучения] 1. [HTTP 401: действительные учётные данные и WWW-Authenticate](https://developer.mozilla.org/ru/docs/Web/HTTP/Reference/Status/401) 1. [HTTP 403: доступ запрещён из-за недостатка прав](https://developer.mozilla.org/ru/docs/Web/HTTP/Reference/Status/403) :::