版權聲明：本作品采用【知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議】進行許可。
一段時間以來研究和實踐契約測試，發現如過去大家對于單元測試、集成測試、端到端測試等等測試理解不一致一樣，絕大多數情況下都把契約測試理解或應用錯了。
為了統一認知，寫了個簡介，以求被拍磚和拍人。
目的（解決的問題）
契約測試是一種以自動化測試作為技術手段，解決團隊間因存在明顯溝通邊界，由溝通不暢和代碼變更而造成的系統間接口不匹配問題的最佳實踐。
原理
https://martinfowler.com/articles/practical-test-pyramid.html
通過測試驅動生成服務間的契約文檔，利用該契約文檔和Mock Server（銀行業常稱之為“擋板”）分別對契約的消費者和提供者進行自動化測試，以確保雙方能夠按照契約實現滿足規格要求的接口，并利用持續集成流水線實現對雙方變更影響的快速反饋。
原則
- 快速反饋
- 契約測試應當聚焦對于接口規則的驗證，能夠易于編寫，快速運行，最簡驗證。所以通常采用測試替身（Test Double）來代替集成組件加快運行速度（速度與單元測試相當）。
- 測試運行時使消費者與提供者解耦（分別運行測試）
- 對于接口的功能驗證，應當由接口集成測試來保證。
- 對于系統間的協作驗證，應當由系統間集成測試，或端到端測試來保證。
- 消費者驅動設計優于提供者驅動設計
- 符合需求拉動和簡單設計思想，減少冗余設計。
適用場景 / 條件
- 契約測試屬于進階自動化測試實踐，團隊需具備基本的自動化測試和持續集成實踐能力，并了解微服務基本知識和概念。
- 系統間采用松耦合的通訊和開發方式，例如HTTP+JSON。而非緊耦合的通訊和開發方式，例如共享接口文件的RPC類框架。
- A團隊與B團隊間存在明顯的溝通邊界，但二者均可控（可采用統一實踐并堅持）。
- 提供者提供的接口被多個消費者消費，需要快速反饋代碼變更所造成的影響。
前置知識與能力
- 自動化測試基礎
- 單元測試
- 集成測試
- 端到端測試
- 測試替身
- 簡單設計（增量式設計）/ 測試驅動開發
- API測試方法
- 版本控制
- 持續集成 / 持續交付
- 微服務
可用工具
-
Pact（推薦）
- 消費者驅動
- Pact Specification 契約規范 + 多技術棧實現
- 基于JSON的契約文件
- 支持HTTP+JSON的接口實現 / 消息隊列
-
Spring Cloud Contract
- 提供者驅動 / 消費者驅動
- JVM + Spring 技術棧，可與Pact Broker集成
- 基于JAR的契約文件
- 支持HTTP+JSON的接口實現 / 消息隊列
