Spring Cloud Contract

时间:2023-02-13 23:29:51

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库。

Spring Cloud Contract

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>