Рассматривали ли вы использование Spring Cloud Contract (http://cloud.spring.io/spring-cloud-contract/)? Это проект, разработанный специально для этой цели.
У вас есть производитель API и его потребители. Идея Spring Cloud Contractи подход Consumer Driven Contract таков, что потребители предлагают, как должен выглядеть API производителя. Они могут создавать прототипы API без написания какого-либо производственного кода на стороне производителя. Прототипирование происходит в форме «контракта».Это может быть файл Groovy или YAML (вы, конечно, можете расширить платформу). Обработка контракта приводит к созданию заглушки WireMock, которую потребители могут использовать в своих интеграционных тестах. Другими словами, это как если бы производителиподготовит небольшую фальшивую реализацию своего кода для тестирования. Таким образом, потребители могут запускать свои интеграционные тесты с заглушкой на стороне производителя. Заглушка была сгенерирована из контракта. Скажем, потребитель X хочет использовать API втакой способчто если запрос GET будет отправлен на /foo, он ответит текстом bar.Затем генерируется заглушка, которая отвечает текстом bar при попадании в конечную точку /foo.
Теперь производители повторно используют одни и те же контракты для генерации тестов, чтобы проверить, соответствует ли их API требованиючто там в контракте.Помните, что GET @ /foo ответит примером bar?Если производитель попытается построить свой проект и не имеет такой конечной точки, его сборка будет нарушена.Среда Spring Cloud Contract генерирует тесты, которые утверждают, работает ли API должным образом.Только после того, как производитель исправит отсутствующую реализацию, сборка пройдет.
Это подход контракта, основанный на потребителе.Вы также можете использовать подход, основанный на продюсере, когда производитель API просто определяет контракты, не сообщая потребителям, как именно каждый из них использует API.
Ценные ссылки:
Примечание: я поддерживаю Spring Cloud Contract.