testing - 为什么消费者驱动的契约(Contract)测试不起作用？

Question

为什么 CDCT 不适用于现实生活中的大多数情况？概念和工具已经被架构师推销好几年了，尤其是微服务架构师，或者多模块的复杂系统，集成测试的痛点很多，但为什么CDCC没有处处落地？

Answer 1

大约三年前听说过CDCT(consumer-driven contract test)的概念和工具，我曾经在我们的企业软件(世界上最复杂的SaaS软件之一，15岁，由一千多名工程师开发)并在大约两年前与我们的首席架构师讨论过。看起来很有希望的是，我们应该能够找到一个真实的案例来通过像 pact 这样的适当工具来实现它，在两个有痛点和动机的适当团队之间，为什么不呢？这个概念非常有意义，它旨在解决的问题是一个非常普遍的问题(谁没有被另一个团队破坏的集成？)，一切看起来都很完美，我什至将其添加到我的年度目标中。

我失败了，我年轻又单纯，没有成功，绝望。

今天我从另一个团队那里听到了同样的失败，毫不奇怪他们有同样的原因，这就是为什么我认为可以把它写下来作为一个提醒和有用的(可能)知识来分享。

原因是高昂的采用成本，包括思维方式的改变。 CDCT 不是一种工具(您可以使用像 pact 这样的工具来更好地实现它)，它甚至不仅仅是一种方法论，它是一种告诉人们如何一起工作的新思维方式。

是的，它旨在解决多个系统/模块之间的问题，但更多的是创造一种新的思维方式，需要两组人接受:首先需要契约(Contract)(而不是不需要契约(Contract))，其次是消费者是契约的驱动(vesus provider 是集成的驱动)。

这是棘手的部分，从消费者的角度来看，需要为集成点做些什么:

在CDCT之前: 1. 找到一个API并使用它。 2. 当它坏了，责怪提供者

CDCT 之后:1. 找到一个 API 2. 驱动:找到供应商，与供应商会面，与供应商谈判，制定契约(Contract)，如果有差距重复此操作，签署契约(Contract)并保存。 3. 编写测试，要求提供商审查测试，要求提供商将您的测试放入他们的管道中。弄清楚如何确保提供商始终让您的测试通过，而不是在他们发布新版本的服务之前将它们注释掉。

我能理解为什么消费者可能不是真的想要这个，或者为什么他们想要结果但犹豫要不要先付钱。

那么 CDCT 实现何时才能成功？我认为可能有两个条件:

1. 消费者的业务太重要了(比如会计)，他们别无选择，只能尽一切努力维护依赖性。然而，在这种情况下，更好的办法是去除依赖，或者添加复制和故障转移机制，测试仍然是最后的选择。

2. 提供者和消费者的合作非常紧密，因此心态和设置成本将是最低的，不幸的是，在这种情况下可能不需要契约(Contract)测试，因为团队的合作非常紧密。

问候，埃米尔