契约测试的必要性

测试金字塔模型

测试是软件流程中很是重要，不可或缺的一个环节。通常的测试分为单元测试，集成测试，端到端的手工测试，这也是构成测试金字塔的三个层级。咱们今天将要讨论的话题是契约测试，它是处于单元测试和集成测试中间的一个环节。这三个层级分别测试的场景以下：

• 单元测试：测试单个service
• 集成测试：测试由多个services组成的系统
• 端到端测试：测试从用户到各个外部系统的整个场景

 

 

什么是契约测试？

 契约测试最开始的概念由Martin Fowler 提出，请参见这篇文章， 它又被称之为：消费者驱动的契约测试（Consumer Driven Contracts）。这里的契约是指软件系统中各个服务间交互的数据标准格式，更多的指消费端（client）和提供端（server）之间交互的数据接口的格式。

为何要存在契约测试？

 系统工程中存在这样的理论：线性系统（即复杂性随规模线性增加的系统）的可靠性等于组成它的各个组件的可靠性之乘积。这容易理解，由于整个系统正常工做的条件是必须每一个组件都同时正常工做。

 

如上图所述，三个组件共同支撑的系统，若是每一个组件的可靠性是90%，那么整个系统的可靠性就是 90%×90%×90%=72.9%，咱们能够看到系统总体的可靠度是低于任一组件的可靠性的。若是一个系统由100个组件组成，每一个组件即便能达到99%的可靠性，那么整个系统的可靠性也会降到36.6%左右。

　　咱们常说复杂性是软件工程的最重要的特性，一个完善的软件系统必然是靠不少的子系统，组件共同撑起来的。根据上面的理论，若是是一个复杂的软件系统那么每个组件的可靠性都对系统总体的可靠性有着很是重要的影响，排除组件自己的可靠性的因素，各个组件之间的相互依赖和调用关系也将会对系统的稳定性有着决定性的影响。随着业务的复杂度愈来愈高，整个系统也变得愈来愈庞大和错综复杂，在今天的软件工程开发中微服务已经不是一个新名词，在微服务的架构下一般一个client会与多个service相互交互，能够想象一下若是某一个服务的接口发生变化将会影响整个系统的运行。以下图展现的传统的大服务与微服务的区别。

那么在微服务模式下若是保证各个服务端与消费端之间以及服务与服务之间可以可靠的交互呢？这就回到了到咱们要聊的契约测试的话题。

以下图，在服务端接口发生变化的状况下经过契约测试能够很容易的测试出契约不匹配，能够在集成测试以前就能发现问题，尽早解决。

 

 

 

契约测试和单元测试，集成测试，端到端测试区别是什么？

单元测试：

• 一般是测试单个类，方法的可靠性
• 它的价值在于快速的反馈某一个很小的功能点是否能准确的工做
• 经过单元测试可以更明确的剖析你的实现逻辑
• 若是用TDD的开发模式，可以作代码重构以及改善代码整洁度

集成测试：

• 关注的是各个服务之间交互
• 测试接口连通性和流程的可用性

端到端测试：

• 从用户的角度验证整个功能的准确性和可用性
• 测试的是端到端的流程，会加入用户数据验证功能是否可用
• 不会关注在某一细小的功能点的实现
• 关注的是整个业务流程，产生的业务价值大

契约测试：

• 测试接口和接口之间的正确性
• 验证服务层提供的数据是不是消费端所须要的
• 将原本须要在集成测试中体现的问题前移，更早的发现问题
• 更快速的验证消费端和提供端之间交互的基本正确性

契约测试解决能解决什么问题？

1. 可使得消费端和提供端之间测试解耦，再也不须要客户端和服务端联调才能发现问题
2. 彻底由消费者驱动的方式，消费者须要什么数据，服务端就给什么样的数据，数据契约也是由消费者来定的
3. 测试前移，越早的发现问题，保证后续测试的完整性
4. 经过契约测试，团队能以一种离线的方式(不须要消费者、提供者同时在线)，经过契约做为中间的标准，验证提供者提供的内容是否知足消费者的指望。

 

通常契约测试是在单元测试以后，集成测试以前要进行的，首先在保证各自功能正确的前提下测试消费者和提供者的契约是否相匹配，而后再进一步的测试功能的完备性和整个业务流的正确性。

写在最后

本文主要浅显的介绍了契约测试是什么以及它的重要性，后续将会继续介绍契约测试的框架以及相关实践。