Как тестировщик взаимодействует с моками для отправки запросов и получения валидных и невалидных ответов

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

Понимаете ли вы, где заканчивается тестируемая система и начинается заглушка, и умеете ли с помощью мока получить ответы, которых от настоящего сервиса не добьёшься. Следом обычно спрашивают: «А как вы узнаете, что мок не разошёлся с реальным API?»

Как отвечать

Тестировщик чаще работает не с объектными моками вроде Mockito (это инструмент юнит-тестов разработчика), а с мок-серверами, которые подменяют внешний HTTP-сервис: WireMock, MockServer, Mockoon, правила подмены в Charles или Fiddler. Приложение настраивают ходить не на реальный адрес, а на мок, и тот отвечает по заданным правилам.

Какие ответы стоит завести:

• валидные: типовой ответ, пустой список, максимальный объём данных, отсутствие необязательных полей;
• невалидные по содержанию: пропущенное обязательное поле, неверный тип, null там, где его не ждут, битый JSON;
• ошибки протокола: 400, 401, 403, 404, 429, 500, 503, у каждого своё ожидаемое поведение клиента;
• сетевые условия: задержка дольше таймаута, обрыв соединения, медленная отдача.

В WireMock это стабы с условием на метод, путь, заголовки или тело и заданным ответом, плюс fixedDelayMilliseconds для задержки и fault для обрыва. Мок записывает пришедшие запросы, поэтому можно проверить и обратную сторону: приложение отправило нужные заголовки, правильное тело, не повторило запрос лишний раз.

Чтобы моки не расходились с реальностью, их сверяют с контрактом: схемой OpenAPI или контрактными тестами (Pact), а часть сценариев всё равно гоняют на настоящем тестовом стенде.

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

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

Проверяют только статус-коды, а не поведение приложения: что увидел пользователь, повторился ли запрос, не упал ли экран.

Держат моки годами без сверки с API. Тесты зелёные, а на проде поле давно переименовано.