為什么是契約測試
契約測試（ContractTest）第一次看到我是在Martin Fowler的文章里。（原文在這里感興趣的可以去看看https://martinfowler.com/bliki/ContractTest.html）

在他的這篇文章了，首先說了一下TestDouble的劣勢，其中TestDouble（對這個定義感興趣可以見https://martinfowler.com/bliki/TestDouble.html）

其實我們也很少提及。為了解釋契約測試，我們在本文吧TestDouble替換成MOCK，這也行并不正確，但是可以快速讓我們理解。

MOCK服務相信很多人都知道主要是用了幫助解決外部依賴而存在的。在兩個團隊分別負責Service1和Service2的開發，其中Service1調用Service2。在測試過程中很容易由于Service1和Service2之間網絡速度、服務不穩定等問題導致的無法測試Service1，那么這個時候我們很多人第一個想到的是Service2用MOCK服務替代掉。這也確實是一個行之有效的方法。

但是現在開發周期、迭代周期和迭代頻率都在變短、變快，如果Service1在開發或者測試的使用應用了Service2的MOCK服務，同時Service2也被自己的Own團隊進行了升級迭代，但是Service1調用的MOCK服務沒有升級，這就導致了集成測試的時候才能發現兩邊不一致的問題，這將大大影響項目或者迭代周期的進度。

在微服務大行其道的今天，各種服務接口（provider）又被各種服務調用（comsumer），生產者消費者模式就促生了契約測試（更應該叫消費者驅動的契約測試，Cunsumer-Driven Contracts，簡稱CDC），CDC就是從消費者的角度定義測試，通過給API提供方提供契約的形式，來完成功能的實現。當今比較主流的CDC測試框架有PACT（https://github.com/pact-foundation/pact-specification）

cdc核心原則(轉自：https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html）:

cdc是以消費者提出接口契約，交由服務提供方實現，并以測試用例對契約進行產生約束，所以服務提供方在滿足測試用例的情況下可以自行更改接口或架構實現而不影響消費者。

cdc是一種針對外部服務的接口進行的測試，它能夠驗證服務是否滿足消費方期待的契約。 它的本質是從利益相關者的目標和動機出發，最大限度地滿足需求方的業務價值實現。

Pact的契約測試流程

如上圖，使用Pact完成契約測試后，首先我們還是按照原來的測試用例對Consumer進行測試，在需要Consumer和Provider發生交互的時候，Provider被替換成和Pact交互。在測試過程中，Pact會記錄下全部的Provider的調用請求（保存在一個Json文件中），這就是消費者的契約。如果在執行Provider的測試的時候，就不需要從新完成Provider的測試用例，只需將Pact記錄下來的消費者契約作為測試的輸入，完成和Provider的交互，來驗證Provider是否滿足了消費者契約。

這也說明了契約測試既不是單元測試也不是集成測試，是出于單元測試和集成測試之間的一層測試行為。

Pact官方給出的幾個場景：
（轉自： https://insights.thoughtworks.cn/about-contract-test/）

適用場景：
團隊能把控開發過程中的Consumer和Provider端
適合Consumer驅動開發的場景
對于每個獨立的Consumer端，Provider端都能管理好需求。

不適用的場景：
公共API或者是OAuth授權服務
Provider端和Consumer端沒有良好的溝通渠道
針對性能的測試
Provider端的功能性測試（Pact只測試內容和請求格式）
對于不同輸入有相同的輸出，并未達到驗證的目的
當前測試輸入需要依賴之前測試返回的結果

參考
https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html
http://aleung.github.io/blog/2017/06/21/pact/
https://insights.thoughtworks.cn/about-contract-test/

?

轉載于:https://www.cnblogs.com/mrtester/p/10490010.html

總結

以上是生活随笔為你收集整理的契约测试：解决微服务测试的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。