Работали ли с тест контейнерами и WireMock

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

Умеете ли вы писать интеграционные тесты, которые проверяют систему, а не моки. Testcontainers и WireMock закрывают две стороны одной задачи: реальные зависимости поднимаются в докере, а чужие HTTP-сервисы подменяются управляемой заглушкой. Ждут понимания, что и когда применять, и цены такого решения по времени прогона.

Как отвечать

Разделите два инструмента и покажите точку подключения к Spring.

• Testcontainers: контейнер с реальной базой, брокером или кэшем поднимается на время тестов. Адрес прокидывается в контекст через @DynamicPropertySource, в свежих версиях Spring Boot есть аннотация @ServiceConnection, которая делает это сама.
• Зачем не H2: на настоящей базе проверяются миграции Flyway или Liquibase, нативные типы, оконные функции и блокировки. H2 в режиме совместимости врёт, и тест зелёный там, где прод падает.
• Скорость: контейнер один на весь прогон, не на класс. Помогают статический контейнер, reuse и откат данных транзакцией либо TRUNCATE между тестами.
• WireMock: описываете ожидаемый запрос и ответ, stubFor(...), потом verify(...) проверяет, что клиент сходил с нужными заголовками и телом.
• Негативные сценарии: именно WireMock удобно заставляет внешний сервис отдать 500, порвать соединение или ответить с задержкой, чтобы проверить таймауты, ретраи и предохранитель.

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

Оставляют H2 для интеграционных тестов и реальную базу видят только в проде. Расхождение диалектов вылезает на первом же специфичном запросе или на миграции, которую тесты просто не исполняли.

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

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