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>