为什么消费者驱动的合同测试不起作用？

Question

为什么CDCT在现实生活中不适用于大多数情况？CDCC的概念和工具已经被架构师销售了好几年，特别是在微服务架构师中，或者在多模块的复杂系统中，集成测试有很多痛苦，但是为什么CDCC不是到处都实现呢？

Answer 1

大约三年前，我听说了CDCT (消费者驱动的合同测试)的概念和工具，我曾经在我们的企业软件(世界上最复杂的SaaS软件之一，已有15年历史，由1000多名工程师开发)中做了一些研究，并在大约两年前与我们的首席arch进行了讨论。这看起来很有希望，我们应该能够找到一个真实的案例，通过像pact这样的适当工具来实现它，在两个有痛点的适当团队之间，所以动机也是如此，为什么不呢？这个概念绝对很有意义，它旨在解决的问题是一个非常常见的问题(谁不会有被其他团队破坏的集成呢？)，一切看起来都很完美，我甚至将其添加到了我的年度目标中。

我失败了，我很年轻，很简单，没有成功，没有希望。

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

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

是的，它的目的是解决多个系统/模块之间的问题，但更多的是创建一种新的思维方式，这需要两组人接受:首先需要一个契约(vesus不需要任何契约)，其次消费者是契约的驱动程序(vesus提供者是集成的驱动程序)。

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

CDCT之前: 1.找到一个API并使用它。2.当它崩溃时，责怪提供商

在CDCT之后: 1.找到API 2.驱动:找到提供商，与提供商会面，与提供商谈判，提出合同，如果有差距，重复这一步，签署合同并保存。3.编写测试，要求提供商审查测试，要求提供商将您的测试放入他们的管道中。弄清楚如何确保提供商总是让您的测试通过，而不是在他们发布新版本的服务之前将其注释掉。

我可以理解为什么消费者可能不是真的想要这个，或者为什么他们想要结果，但不愿先支付成本。

那么什么时候CDCT实现会成功呢？我认为可能有两个条件：

1. 消费者的业务太重要了，不能被破坏(比如会计)，他们别无选择，只能竭尽所能地维护这种依赖性。然而，在这种情况下，更好的想法是删除依赖，或者添加重复和故障转移机制，测试仍然是最后的选择。
2. 提供商和消费者正在密切合作，因此心态和设置成本将是最低的，不幸的是，在这种情况下可能不需要合同测试，因为团队的合作非常紧密。

你好，埃米尔