Unit测试使得开发人员可以快活地活在自己的世界中每个开发团队根据图纸造出系统的一个部件只有当这些小部件集成在一起之后能够根据用户的期望为用户提供服务才体现出了系统业务价值。所以我们要通过系统集成测试（UI测试）来保证集成的质量。
微服务架构的庞大度不仅体现在技术上与之相辅相成的是系统的业务架构而技术架构总是服务于业务架构。优秀的测试计谋和工程技术实践让我们更好地构建庞大的架构体系并克服它所带来的挑战而最终决议一个系统乐成与否在于人。所以团队中每一小我私家应该保持Open的心态连续学习提升自己的高度（技术和业务）掌握实施微服务的相关技术好比使用DDD去做服务的划分从而能够更好的驾驭微服务架构。
那么在编码测试方面又有什么招来保证微服务架构下系统的质量？
没有绝对的对与错凭据自身项目工程和技术能力选择适合团队的计谋。
消费者驱动契约测试中存在一个契约双方基于契约生成可事情的测试套件：
陪同着互联网的快速生长Web应用系统从面向企业内部生长到面向市场用户业务的日趋庞大以及用户量的上升那些曾经事情良好的单体应用开始遇到开发、测试、部署、公布各个方面的瓶颈诸如扩展新增功效艰难、系统庞浩劫以维护、编译太耗时公布流程太慢等问题困扰着开发团队。
回首一下引入Contract观点的集成测试之所以会泛起协议的修改直到集成情况中才袒露出来是因为缺乏自动化监控机制来提前发现问题并预警。让我们做进一步深入思考：把同一份API契约作为服务提供方和服务消费方的测试断言依据一旦契约被一方改动则另一方的测试便会失败。
前后端本质上等价于服务提供方和服务消费方所以该理念运用在微服务之间的集成测试中系统的测试架构会获得进一步演进：
8.CDCT(消费者驱动契约测试)
我么在享受着它带来的利益的同时问题也偷偷地潜入系统中。不久后CI就报警了：UI测试测试挂了
归根结底我们缺乏一种有效的强制约束来约束双方马上要揭晓的消费者驱动契约测试可以提供这种约束。
这些痛点在很大水平上会削减一个开发团队的生产力某些企业会雇一个QA举行重复的人工测试从而解放开发人员的生产力。这种措施有悖于追求卓越的理念并没有从本质上解决系统的集成的质量问题。
既然UI测试已经不适用引进了微服务架构的开发团队要如何保证服务集成的质量我们还需要在自动化测试门路上另辟蹊径。
问题难定位修复时间太长影响Pipeline的推进。
10.何去何从
存在大量重复测试已经测试的功效。
在这种单线流水线模式下如果团队的自动化实践做得很好开发人员只需要关注自己编写代码时所编写的测试的质量和数量。
整个应用的测试计谋简朴直接:
5.系统级的集成（UI）测试
4.服务自身的Unit测试
CDCT具备了引入Contract观点集成测试的诸多优点而且通过可事情的测试套件保证了契约的一致性和实时性。
消费者驱动契约测试的流程是消费者界说他们期望的API或消息是什么样子这些期望即为契约从这些契约可以生成存根今后消费者团队可以在构建历程中重复使用它们。消费者和生产者都需要验证契约。
三国明星诸葛亮卖力运筹帷幄关、张、赵等武将卖力赴汤蹈火从而决胜千里之外的硝烟战场。团队确定了测试计谋之后应当交由优秀工具来实施执行。
3.微服务测试的演变
运行速度慢反馈周期长。
存在重复测试已测试的功效。
如果团队正在开发一个Springboot应用Spring cloud Contract 是一个不错的选择。它使用Groovy DSL界说测试契约并生成测试套件测试套件去验证服务提供方是否满足契约测试通过之后会生成一个jar文件该jar文件随后会作为一个可运行的Stub server消费方基于Stub server编写测试从而验证功效是否满足契约：
当我们的意识中只存在一样工具的时候我们便可以不假思。
本文来源：云开平台-www.voyage68.com
