testing - 为什么消费者驱动的合同测试不起作用？
问题描述
为什么CDCT不适用于现实生活中的大多数情况？这个概念和工具已经被架构师推销了好几年了，特别是在微服务架构师，或者在多模块复杂系统中，集成测试有很多痛苦，但是为什么CDCC没有到处实现呢？
解决方案
大概三年前听说过CDCT（consumer-driven contract test）的概念和工具，曾经对我们的企业软件（世界上最复杂的SaaS软件之一，15岁，由more超过一千名工程师）并在大约两年前与我们的首席拱门讨论过。看起来很有希望的是，我们应该能够在两个有痛点的适当团队之间通过适当的工具（如协议）找到一个真实的案例来实施它，所以动机也是如此，为什么不呢？这个概念非常有意义，它旨在解决的问题是一个非常常见的问题（谁没有被另一个团队破坏的集成？），一切看起来都很完美，我什至将其添加到我的年度目标中。
我失败了，我年轻而单纯，没有成功，绝望。
今天我从另一个团队听到同样的失败，毫不奇怪他们有同样的原因，这就是为什么我认为它可能会写下来作为提醒和有用的（可能）知识分享。
原因是高昂的采用成本，包括思维方式的改变。CDCT 不是一种工具（您可以使用诸如 pact 之类的工具来更好地实施它），它甚至不仅仅是一种方法论，它是一种告诉人们如何一起工作的新思维方式。
是的，它旨在解决多个系统/模块之间的问题，但更多的是创造一种需要两组人接受的新思维方式：首先需要合同（不需要合同），其次消费者是驱动力合同（vesus 提供者是集成的驱动力）。
这是棘手的部分，从消费者的角度来看，集成点需要做什么：
CDCT之前： 1.找到一个API并使用它。2.当它坏了，责怪提供者
CDCT之后： 1.找到API 2.驱动：找到供应商，与供应商会面，与供应商协商，签订合同，如果有差距，重复此操作，签署合同并保存。3. 编写测试，请提供者审查测试，请提供者将您的测试放入他们的管道中。弄清楚如何确保提供者始终使您的测试通过，而不是在他们发布新版本的服务之前将其注释掉。
我可以理解为什么消费者可能并不真正想要这个，或者为什么他们想要结果却不愿先支付成本。
那么CDCT何时实施会成功呢？我认为可能有两个条件：
消费者的业务太重要了，不能被破坏（比如会计），他们别无选择，只能尽一切努力维护依赖。但是，在这种情况下，最好的办法是删除依赖关系，或者添加复制和故障转移机制，测试仍然是最后的选择。
提供者和消费者的合作非常密切，因此心态和设置成本将是最低的，不幸的是，在这种情况下可能不需要合同测试，因为团队合作非常密切。
问候， 埃米尔