Я не уверен, используется ли spring-cloud-contract для упомянутой мною цели в заголовке правильно или нет, но я хочу понять его вариант использования в таком сценарии.
Мы обновляем наши интеграционные тесты, чтобы использовать Spring Cloud Contract. Что касается новых функций, мы следуем документации по созданию заглушек из YAML / Groovy, а затем используем их на стороне потребителя с помощью spring-cloud-starter-contract-stub-runner.
Меня беспокоят уже написанные и используемые заглушки. Мы не хотим тратить время на их переписывание в Groovy / YAML, чтобы сделать Spring Cloud Contract для генерации заглушек, поскольку заглушки у нас уже есть. Существующая тестовая конфигурация выглядит следующим образом:
@SpringBootTest(
webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
classes = Application.class
)
@AutoConfigureWireMock(port = 8989, stubs = "classpath*:**/stubs/mappings/**/*.json", files = "classpath*:**/stubs")
class MyClientIT { ... }
Когда дело доходит до изменения этого теста для использования spring-cloud-contract, я застрял с тем, как настроить stub-runner:
@SpringBootTest(
webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
classes = Application.class
)
@AutoConfigureMockMvc
@AutoConfigureStubRunner(???)
public class MyNewClientIT {...}
Можно ли и рекомендуется ли использовать Spring Cloud Contract для такого случая? И если да, то как мы можем сделать так, чтобы stub-runner видел локально сохраненные (не сохраненные как артефакт локально или удаленно) заглушки?
Спасибо...