Spring Cloud Contract

http://www.infoq.com/cn/news/2017/04/spring-cloud-contract

在默認狀況下，咱們但願用戶以JAR文件的形式將生產者存根和契約發佈到Maven庫。假如存根的組ID爲「org.springframework」，工件ID爲「spring-boot-application」。爲了運行存根，消費者須要像下面這樣給測試加上註解：@AutoConfigureStubRunner (ids={'org.springframework:spring-boot-application:+'}

實際狀況是，框架會自動下載包含存根的「org.springframework:spring-boot-application」 JAR文件的最新版本，而後啓動一個內存內HTTP服務器，並在一個隨機端口上提供存根。也就是說，只需一條註解，你就能夠爲構建生成整個環境的存根！此外，真正有趣的是，Spring Cloud Contract能夠徹底消除服務發現工具。那意味着，存根註冊在一個服務註冊中心的內存版本中。那樣，你能夠像使用服務發現那樣，向一個真正的HTTP服務器發送一個真正的HTTP請求。

若是你想要在測試環境中對打包好的應用程序執行一些冒煙測試，Spring Cloud Contract的Stub Runner也很是方便。下載好的存根能夠註冊到真正的服務發現工具中（例如Eureka），在契約中定義的真正的消息能夠發送給真正的隊列（例如RabbitMQ）。那樣，你的應用程序甚至都不知道它在同存根交互。

 

InfoQ：給我介紹下新的Spring Rest Docs集成吧，它是否能夠改變傳統的消費者驅動契約工做流？

Grzejszczak：那不新了，不過，它確實得到了更多的關注。有些用戶不喜歡編寫Groovy DSL，不但願生成測試。他們但願徹底屬於本身的測試流程。還有一些其餘的用戶已經在使用Spring Rest Docs測試他們的代碼。Dave Syer就是其中的一位用戶，向Spring Rest Docs添加Spring Cloud Contract集成就是他的主意。多虧了這個，你才能編寫測試來測試你的Web應用程序以及自動生成存根。使用Spring Cloud Contract的最新版本，你還能夠從Spring Rest Docs生成Groovy DSL契約。

至於工做流，我能夠想象獲得，消費者和開發者結對知足消費者須要的測試和存根。那樣，流程得以保留。另外一方面，有些事情告訴我，Spring Rest Docs方法將更多地應用在「生產者契約」方法中。生產者定義契約是什麼樣子也是如此。在Spring，咱們喜歡用本身的產品來進行開發，Spring Initilizr（start.spring.io背後的代碼）已經使用了Spring Cloud Contract，並且，Spring Initilizr存根發佈到了Spring的Maven庫。

 

http://www.cnblogs.com/zhangjianbin/p/7567134.html

在CI / CD環境中工做

到目前爲止，咱們只看到如何在本地機器上開發CDC的新功能。與包/構建管道集成須要更多的調整：

• 默認狀況下，生產者的Gradle構建任務將生成並運行合同驗證程序測試。它只須要經過添加uploadArchives到其Gradle任務將存根jar發佈到遠程存儲庫。
• 該消費者須要配置StubRunner解決存根。這能夠經過設置Spring Boot應用程序屬性來實現：

stubrunner:
    ids: com.demo:account-service:+:stubs:8082 repositoryRoot: https://demo.jfrog.io/demo/libs-snapshot</pre>