Есть ли опыт создания заглушек для интеграции

Что проверяют

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

Как отвечать

Стройте ответ на своём примере: какой внешний сервис подменяли (платёжный шлюз, СМС, партнёрский API), зачем, чем и какие сценарии покрыли. Эффект в цифрах только реальный.

Опорные пункты:

• термины: stub возвращает заранее заданные ответы, mock ещё проверяет, как его вызвали, fake это упрощённая рабочая реализация, например база в памяти;
• инструменты: WireMock (отдельным сервером или внутри JUnit), MockServer, Mockoon и мок-серверы Postman для быстрых сценариев, Prism для заглушки по OpenAPI. В Python-тестах responses или pytest-httpserver;
• сценарии: не только 200 с успешным телом, но и 4xx, 500, таймаут, задержка, обрыв соединения, битый JSON. В WireMock это withFixedDelay и withFault, а смена состояний вроде «платёж в обработке, затем проведён» делается через inScenario;
• актуальность: заглушки по контракту OpenAPI, запись реальных ответов в режиме record, контрактные тесты вроде Pact, которые падают, если провайдер поменял формат;
• границы: заглушки ускоряют и стабилизируют тесты, но прогон против настоящего стенда партнёра всё равно нужен.

Если опыта не было, скажите прямо и покажите понимание: вы поднимали WireMock на учебном проекте или делали мок в Postman и знаете, какие сценарии покрыли бы первыми.

Где спотыкаются

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

Называют Mockito заглушкой для API. Он подменяет объекты внутри кода в юнит-тестах, а внешний HTTP-сервис в интеграционном тесте подменяется сетевой заглушкой.

Не обновляют заглушки после изменения API партнёра: тесты зелёные, а на проде интеграция падает.