持续测试能够推动快速反馈，从而避免测试工程师提出一个缺陷，开发工程师就要翻出几周前开发的代码，重新整理思路再修复对应的缺陷。此外，每次完成测试后，系统的干系人希望能够确认测试是一个充分并且合适的测试，既没有多测试，也没少测试。这些持续交付的需求推动了持续测试技术的发展。本章详细介绍持续测试中测试技术的发展。
5.1 契约测试
契约测试（contract test）第一次出现在Martin Fowler的一篇文章中。该文章首先介绍了测试替身（test?double）的劣势，其中测试替身代表为了达到测试目的并且减少对被测对象的依赖，使用“替身”代替一个真实的依赖对象，从而保证测试的速度和稳定性。当今开发过程中，经常会遇到待测系统依赖组件而造成的测试阻碍，这是严重影响项目交付的风险之一，而测试替身就是规避这个风险的手段。
在测试过程中，使用测试替身（替代真实的依赖组件）和待测系统进行交互，测试替身不必和真实的依赖组件的实现一模一样，如不用实现依赖组件复杂的内部逻辑等。只需要在满足测试需求的范围内，对于被测系统来说，确保测试替身提供的API与依赖组件提供的一样即可，API具体怎么实现的并不重要。
使用测试替身也不是万能的，虽然可以使用它提高测试效率，但是它毕竟不是最终要依赖的系统，因此还需要进入真实的系统集成测试，真正完成一次正确的业务流程验证。测试替身也是一类解耦技术的总称，可以进一步细分，如表5-1所示。
表5-1 测试替身的分类
无论使用哪种测试替身服务，都是为了帮助解决外部依赖。现在两个团队分别负责Service1和Service2的开发，其中Service1调用Service2。在测试过程中很容易因Service1和Service2之间的网络速度、服务不稳定等问题而无法测试Service1，这时测试工程师首先想到的是用测试替身服务替代Service2。这也确实是一个行之有效的方法。
但是现在开发周期、迭代周期都在变短，迭代频率不断变快，如果在Service1的开发或者测试过程中使用基于Service2的测试替身服务，同时Service2也被自己负责的团队进行升级迭代，但是Service1调用的测试替身服务没有升级，这就导致集成测试时才能发现两边不一致的问题，这将大大影响项目的进度。
在微服务盛行的今天，各种服务接口又被各种服务调用。生产者-消费者（provider- comsumer）模式促生了契约测试，契约测试应该称为消费者驱动的契约测试（Cunsumer-Driven Contract Testing，CDCT）。
契约测试从消费者的角度定义测试，通过给API提供方提供契约，实现功能。契约测试的核心原则是由消费者提出接口契约，由服务提供方实现，并用测试用例对契约进行约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。
契约测试是一种针对外部服务接口进行的测试，它能够验证服务是否满足消费方期待的契约。它的本质是从利益相关者的角度出发，最大限度地满足需求方的业务价值实现。
当今比较主流的契约测试框架是Pact，其工作原理如图5-1所示。
图5-1 Pact的工作原理
使用Pact完成契约测试后，先按照原来的测试用例对消费者（comsumer）进行测试，在需要消费者和生产者（provider）交互时，使生产者与Pact交互。在测试过程中，Pact会记录全部生产者调用请求（保存在一个JSON文件中），这就是消费者的契约。在执行生产者的测试时，无须重新完成生产者的测试用例，只需要以Pact记录下来的消费者契约作为测试的输入，完成与生产者的交互，来验证生产者是否满足消费者契约。这说明契约测试既不是单元测试也不是集成测试，是处于单元测试和集成测试之间的一层测试行为。
如果团队不仅能自主把控开发过程中的消费者和提供者并推动消费者驱动开发的实施，还可以管理每个独立的消费者端的提供者端需求，那么适合使用Pact这类契约测试实践。
然而，在以下场景下目前并不适合应用Pact这类契约测试实践：
在测试过程中，代码需要调用公共API或者OAuth授权服务；
提供者端和消费者端没有良好的沟通渠道；
对提供者端进行功能性测试；
对于不同输入有相同的输出，并未达到验证的目的；
当前测试输入需要依赖之前测试返回的结果。
