Как работает мок платежного сервиса

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

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

Как отвечать

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

• в коде (unit): Mockito, unittest.mock, jest.fn() подменяют клиент шлюза, например PaymentGatewayClient, а тестируется ваш OrderService, который его вызывает;
• HTTP-заглушка: WireMock или MockServer поднимают сервер с правилами ответов: успех, отказ с кодом ошибки, задержка на 30 секунд для проверки таймаута;
• песочница провайдера: тестовый режим шлюза с тестовыми картами. Это уже не мок, а реальная интеграция без денег, её гоняют реже.

Через мок стоит проверить успешную оплату, отказ (нет средств, не пройден 3-D Secure), таймаут и обрыв соединения, повтор запроса с тем же ключом идемпотентности, вебхук, который пришёл дважды или раньше ответа на запрос. Отдельно проверяют, что система отправила в шлюз: сумму, валюту, номер заказа (verify в Mockito, журнал запросов в WireMock).

Чтобы мок не разошёлся с настоящим API, ответы строят по документации провайдера и время от времени сверяют с песочницей. Для внутренних сервисов эту задачу решают контрактные тесты, например Pact.

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

Мокают тот самый класс, который тестируют. Тест вызывает processPayment у мока и проверяет, что мок вернул заданный ответ. Такой тест проверяет Mockito, а не вашу логику.

Проверяют только успешный платёж. Основные дефекты в платежах живут в отказах, таймаутах и повторах: двойное списание, заказ навсегда завис в статусе «ожидает оплаты».

Не могут объяснить разницу между стабом и моком. Стаб просто отдаёт ответ, мок ещё и проверяет, как к нему обратились: сколько раз и с какими параметрами.