契约测试与CD的整合
最开始，我们的pipeline是这样的，单元测试是独立的测试，当通过单元测试后运行集成测试。此时集成测试成为了系统瓶颈，而且一旦集成测试失败，就必须被迅速修复，其他pipeline只能等待其修复，否则任何新的变更都会测试失败。
一个解决办法是将集成测试分散在每个pipeline上，每次集成测试运行的版本是当前的最新代码和其他系统的上一次通过版本之间的测试。这样解决了测试的独立性以及不会阻碍其他pipeline测试的效果，然后将通过测试的不同系统的package按照版本保存。但是这样一来，集成测试的缺点就更为明显提现出来，第一是系统部署时间长，每次集成测试需要运行同样的测试在不同pipeline上，增加了测试成本和反馈周期。
接下来，我们使用契约测试替代集成测试。这样有几点好处不仅解决了独立测试的目的，同时解决了集成测试慢和部署时间长等问题。
为了保证契约测试的正确性，契约文件由Consumer端生成，然后Provider端来实现API，我们使用CDCT来改造我们的pipeline。
我们先假设B系统希望A系统提供新功能，如果按照图中黄色步骤来提交的话，则会测试失败，原因在于此时，契约文件是最新的B-A.consumer.1.1.pact与之对应A-B.provider.1.0.jar不是最新的，所以测试失败。
按照图中步骤2运行，当提交A的pipeline时，当前版本的A已经升级到1.1，而契约文件还是1.0版本，没有break测试的情况下，最终将A-B.provider.1.1.jar提交到服务器上。
然后按照图中步骤3运行，A-B.provider.1.1.jar和B-A.consumer.1.1.pact完美契合，最终又将B-A.consumer.1.1.pact提交到服务器。所以，改成CDCT之后，虽然产生了一定的提交顺序依赖，但是带来的更多的好处是确保契约文件的产生是调用端提出，并且保证当前最新，确保系统的正确性。
喜欢思考的同学不难发现，CDCT存在自身的缺陷，一个简单的例子是当B存在一个已有的契约约束A的一个功能，当B需要A更新其API时，是先提交B的契约测试，还是更改A的功能到最新版本？其实二者都不可行。
解决办法万变不离其宗，就是大家熟悉的不能再熟悉的重构心法，由王建总结的十六字箴言：
我们分五步来完成API的更新：
Provider端提交一个新的API来保证新功能，同时旧的API功能不变，提交并通过测试。
将Consumer端API的调用指向Provider端的新API，并更新契约文件以约束新功能。
将Provider端旧API同步更新为新API，提交并通过测试。
将Consumer端指回旧有API，其他保持不变。
将Provider端临时过渡的新API删除。
至此，我们解决了API更新时如何保证契约测试的提交顺序，如果是删除API，则直接删除Consumer端的契约测试即可。
需要思考的问题：
1.如果并行测试的话，谁先提交成功的版本，另外一个测试是否要重新运行？
设想，当两个并行pipeline A和B，同时运行时，A中跑的是A1.1和B1.0，B中跑的是B1.1和A1.0的测试，假如双方均能通过各自的测试，但是新版本不兼容（A1.1和B1.1测试失败），双方都将各自的新版本保留，这样就造成了存在相互不兼容的两个版本。目前解决方案是，人为制造一个“瓶颈”，保证同时只有一个契约测试在运行，保存的只有一个版本。
2.契约测试可维护性如何？
构建契约测试类似于单元测试，并且在Pact的框架下十分方便维护。但是，测试框架本身还有一些问题，诸如，大小写敏感，空值验证，只有一份契约文件，契约测试分组等。
（以上是基于pact 1.0的实践，pact2.0使用了正则表达式以及TypeMatching等机制解决了验证“具体”值的问题，更多详细内容请关注pact官方文档）
结语
契约测试不是银弹，它不是替代E2E测试的终结者，更不是单元测试的升级换代，它更偏向于服务和服务之间的API测试，通过解耦服务依赖关系和单元测试来加快测试的运行效率。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
