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