爲何要拋棄Pact？如何快速實現契約測試（CDC）

前言

在前幾天的博客中，我轉載了一篇文章，其中介紹了契約測試和pact是怎麼實施的，的確頗有幫助。但我通過研究，實際上是pact自己也是有缺陷的，結合我近期在使用的服務型工具和個人實際狀況，以爲實現契約測試其實有更有效率的解決方案，本文就經過個人視角看看我是如何快速實現契約測試的。

契約測試

爲先後端對接的過程當中會出現信息不對稱，以及工做進度不一致的狀況，所以但願經過事先約定好API返回數據的文檔，根據文檔來開發後端代碼，以及生產能夠被前端調用的虛擬的API，幫助先後端可以同時開展工做而且保持先後端代碼的正確性，加快後期的系統集成測試甚至是取消系統集成測試。

咱們將以上的作法稱之爲契約測試。契約測試最開始的概念由 Martin Fowler 提出，它又被稱之爲：消費者驅動的契約測試（Consumer Driven Contracts），簡稱CDC。這裏的契約是指軟件系統中各個服務間交互的數據標準格式，更多的指消費端（client）和提供端（server）之間交互的API的格式。

契約測試帶來的變化主要是：

1.將先後端測試解耦，先後端能夠分別在對方尚未完成工做的時候就開展測試；

2.將測試過程前移，加速或者取代集成測試；

3.保證數據的一致性，讓後端服務返回的數據就是前端想要獲得的。

我作了一張圖方便你們理解CDC的概念：

上圖經歷了三個步驟：

1.消費者（廣義的前端）根據業務須要編寫好契約文件，契約文件裏面編寫了須要返回的數據；

2.消費者（廣義的前端）向契約文件（其實是一個API服務）發起請求，獲得預期的結果，驗證前端業務邏輯是否正確；

3.契約文件（其實是一個API服務）向提供者（廣義的後端）發起請求，獲得後端真實的返回結果而且與契約文件中的數據規則進行校驗，判斷後端返回的數據是否知足契約的要求。若是沒法經過校驗，說明提供者的服務發生了改變，或者是沒有按照契約所規定的來進行開發。

若是經過了上面的三步，咱們能夠認爲先後端對於契約的理解和實現是一致的，等到真正集成以後也不會出現問題。

Pact 契約測試框架

以前業內較爲常見的作法是經過Pact（一個契約測試框架）進行契約測試：經過前端開發人員編寫代碼進行測試並生成Pact契約文件，後端經過Pact Brocker等服務管理契約以及調用等。

可是Pact也存在一些缺點：

1.須要引入Pact的相關文件以及正確搭建服務，用起來須要必定的時間成本

2.生成的返回數據不夠靈活，沒法編寫代碼生成複雜的隨機數據；

3.沒法判斷請求參數來返回不一樣的結果；

4.須要開發人員額外編寫代碼，增長了工做量；

5.存在代碼入侵的狀況，而且目前支持的語言較少；

6.模糊了開發與測試人員之間的界限，管理不當容易致使重複勞動；

因爲有以上的不足之處，Pact 在實際應用的效果每每並不理解。所以咱們提出了經過 Mock API 以及測試用例實現更快速、更有效地契約測試。

經過 EOLINKER API Studio 實現契約測試

EOLINKER API Studio（https://www.eolinker.com） 提供了UI實現的 Mock API，配合API Studio 的測試用例與自動化測試，能夠幫助研發團隊更快速、更有效地實現契約測試。

什麼是Mock API？

經過 Mock API，您能夠事先編寫好 API 的數據生成規則，由 API Studio 動態生成 API 的返回數據。開發人員經過訪問 Mock API 的 URL 來得到所須要的數據，完成對接工做。

在 API Studio中，同一個項目中的 Mock API 的地址前綴是相同的（如mock.eolinker.com/uasyd1/…），所以能夠在代碼中將 Mock API 的地址前綴做爲全局變量，項目上線時僅需替換變量的值便可改變整個項目的 API 請求地址前綴。

建立Mock API，實現前端的契約測試

在EOLINKER API Studio中，建立 Mock API 以前須要先建立API文檔（或者導入Postman、Swagger等數據），API文檔能夠做爲先後端對接的依據。這裏我建立了一個簡單的用戶登陸API文檔：

建立好API文檔以後，點擊 Mock API 標籤進入Mock API的管理頁面，在這裏能夠快速建立多個Mock API，而且根據不一樣的請求參數返回相應的數據：

建立一個 Mock API 指望，咱們但願當傳遞user_name=和user_psw=112233時，Mock Server返回登陸成功的數據，這裏返回的數據類型選擇Json，填寫好Json的格式以及內容便可：

點擊預覽按鈕能夠看到是咱們但願獲得的返回數據，而後肯定保存便可：

經過這種方式能夠建立多個Mock API，而且經過請求紅框處的 Mock API URL 獲得返回結果：

API Studio 中也提供了強大的 API 測試的功能，咱們直接在平臺上對剛纔的登陸成功的 Mock API 發起請求，能夠看到當咱們傳遞正確的參數時，能夠獲得預期的返回結果，至此契約測試的前端契約就已經完成了：

建立測試用例，實現後端的契約測試：

傳統的契約測試其實並不可以保證測試的覆蓋率，由於前端開發人員提供的契約文件極可能沒法覆蓋全部的請求狀況，致使出現漏測的狀況。

所以 API Studio 建議將後端的契約測試交給測試人員負責，這樣能夠提供更完善的測試用例，而且能夠結合各種CI工具實現自動化測試。

因爲 API Studio 基於 API 文檔來實現契約測試、API用例測試、API自動化測試等功能，所以能夠將前端、後端、測試人員解耦，工做的流程能夠進一步改進爲下圖所示，先後端、測試人員能夠同時開展工做，而且測試用例能夠導入到自動化測試中成爲長期的定時測試任務。

因爲測試用例與自動化測試所包含的內容較多，若有須要能夠前往 EOLINKER API Studio 官方網站（https://www.eolinker.com）或者是查閱 API Studio 幫助文檔，在此再也不贅述。