【问题标题】:When using Spring Cloud Contracts, why is the producer creating the contracts?使用 Spring Cloud Contracts 时,为什么生产者要创建合约?
【发布时间】:2018-12-24 22:06:04
【问题描述】:

我一直在玩 Spring Cloud Contracts。到目前为止,这是我对工作流程的理解。

在服务器端

  • 编写合约(在 groovy 或 yaml 中)
  • 自动生成测试(使用 gradle 插件)
  • 设置基类,为控制器进行适当的设置设置
  • 运行自动生成的测试
  • 将生成的 stubs jar 文件发布到某个本地 repo(其中包含内置的 wiremock 服务器,带有请求/响应)

在客户端

  • 下载存根 jar 文件
  • 针对这个存根 jar 编写测试。使用 stubrunner 验证响应

我不明白的是这个消费者是如何驱动的?合同似乎来自生产者,消费者似乎在被动地测试生产者发布的内容(使用存根 jar 文件)。生产者可能不小心没有更新合约,而是做出重大更改。这可能导致客户端测试通过,即使它应该失败。这是真的还是我误解了从消费者方面创建合同的步骤

想法?

【问题讨论】:

  • 您所描述的是生产者,而不是消费者,驱动。如果生产者进行了重大更改并且合约没有更新,它将无法通过验证。
  • 我的困惑在于工作流程,在我看到的所有示例中,生产者生成合同,消费者只是针对这个 jar 文件执行测试。如果消费者端的测试失败,是否期望消费者团队与生产者团队交谈并传达失败?在我看来,这不是消费者驱动的。
  • 为什么看起来是消费者驱动的?它不是;正如你所说,生产者生成合同,生产者只是针对它进行测试。
  • 但是 Spring Cloud 合约不是应该促进 Consumer Driven Contract 测试吗? CDC 的主要优势之一是通过自动化测试让生产者知道他们何时引入了重大更改。让每个消费者负责确保他们与生产者兼容似乎违反了 CDC(很有可能,我可能弄错了 CDC,在这种情况下请纠正我)

标签: spring-cloud consumer spring-cloud-contract


【解决方案1】:

消费者驱动合同 (CDC) 开发基本上是一个测试驱动开发 (TDD) 扩展到生产者-消费者应用程序。由于它是 TDD - 测试应该首先出现,然后是实现。而且由于它是消费者驱动的 - 消费者为生产者创建测试

所以让我们假设我们有一个生产者和一个消费者以及一些需要实现的新feature。在 CDC 中,工作流程如下(您可以在official documentation 中找到更多信息)。

在消费者方面:

  • 为该功能编写缺少的实现
  • 在本地克隆 Producer 存储库
  • Producer 的存储库中本地定义合约(并为其自动生成单元测试)
  • 运行集成测试(在消费者方面)
  • 提交拉取请求

在生产者方面:

  • 接管拉取请求(cosumer 已在此处生成测试)
  • 编写缺少的实现(TDD 样式)
  • 部署您的应用
  • 在线工作

现在一切都说得通了,因为 consumer 为新功能编写合同(但在 生产者的 存储库中) - 我们有一个 Consumer Driven Approach

【讨论】:

  • 这对我来说很有意义,但在我看来这不是一种可扩展的方法。作为许多服务的消费者,不可能期望我克隆属于另一个团队的源代码,能够构建并添加合同测试。感觉太多的责任放在了消费者身上。想法?
  • 好吧,每种方法都只在特定情况下才有意义——没有“银弹”。如果您正在评估 CDC 并发现它不适合您 - 您应该根据您的需要对其进行更多调整或检查另一个。
  • 您还可以将合同存储在存储所有联系人的外部存储库中。
猜你喜欢
  • 2018-06-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多