Что такое WireMock и как он используется для мокирования клиентов

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

Умеете ли вы изолировать тесты от внешних сервисов и на каком уровне ставите границу. WireMock подменяет не Java-объект, а сам HTTP, поэтому за вопросом стоит понимание, что именно остаётся непроверенным при обычном моке клиента.

Как отвечать

WireMock это HTTP-сервер-заглушка: он поднимается в тесте, принимает запросы вашего клиента и отвечает заранее описанными ответами. Проверяется весь путь, включая сборку URL, заголовки, сериализацию тела, настройки таймаутов и ретраев, чего мок интерфейса не даёт.

@RegisterExtension
static WireMockExtension wm = WireMockExtension.newInstance().build(); // порт динамический

wm.stubFor(get("/api/orders/17")
    .willReturn(okJson("{\"status\":\"PAID\"}")));

wm.verify(getRequestedFor(urlEqualTo("/api/orders/17")));

Что назвать помимо базового стаба: сопоставление по методу, пути, параметрам, заголовкам и телу, в том числе по JSON-пути; verify как доказательство, что клиент действительно сходил и с теми данными; сценарии с состоянием, когда второй вызов отвечает иначе первого; задержки и обрывы соединения для проверки таймаутов и предохранителя; запись реального трафика в режиме прокси; отдельный standalone-режим, когда заглушка нужна не тесту, а стенду. Адрес заглушки отдают приложению настройкой, а не константой в коде.

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

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

Не чистят стабы и не проверяют вызовы. Заглушки предыдущего теста влияют на следующий, порядок запуска становится значимым, а без verify зелёный тест может не вызывать вообще ничего.

Описывают только успешный ответ. Ценность заглушки как раз в плохой погоде: код 500, пустое тело, неожиданное поле, медленный ответ, разрыв соединения. Именно там выясняется, что ретрай бесконечный, таймаут не выставлен, а ошибка наружу уходит без объяснения.