版權聲明：本作品采用【知識共享署名-非商業(yè)性使用-禁止演繹 4.0 國際許可協(xié)議】進行許可。

一段時間以來研究和實踐契約測試，發(fā)現(xiàn)如過去大家對于單元測試、集成測試、端到端測試等等測試理解不一致一樣，絕大多數(shù)情況下都把契約測試理解或應用錯了。

為了統(tǒng)一認知，寫了個簡介，以求被拍磚和拍人。

目的（解決的問題）

契約測試是一種以自動化測試作為技術手段，解決團隊間因存在明顯溝通邊界，由溝通不暢和代碼變更而造成的系統(tǒng)間接口不匹配問題的最佳實踐。

原理

https://martinfowler.com/articles/practical-test-pyramid.html

通過測試驅動生成服務間的契約文檔，利用該契約文檔和Mock Server（銀行業(yè)常稱之為“擋板”）分別對契約的消費者和提供者進行自動化測試，以確保雙方能夠按照契約實現(xiàn)滿足規(guī)格要求的接口，并利用持續(xù)集成流水線實現(xiàn)對雙方變更影響的快速反饋。

原則

• 快速反饋
  • 契約測試應當聚焦對于接口規(guī)則的驗證，能夠易于編寫，快速運行，最簡驗證。所以通常采用測試替身（Test Double）來代替集成組件加快運行速度（速度與單元測試相當）。
• 測試運行時使消費者與提供者解耦（分別運行測試）
  • 對于接口的功能驗證，應當由接口集成測試來保證。
  • 對于系統(tǒng)間的協(xié)作驗證，應當由系統(tǒng)間集成測試，或端到端測試來保證。
• 消費者驅動設計優(yōu)于提供者驅動設計
  • 符合需求拉動和簡單設計思想，減少冗余設計。

適用場景 / 條件

1. 契約測試屬于進階自動化測試實踐，團隊需具備基本的自動化測試和持續(xù)集成實踐能力，并了解微服務基本知識和概念。
2. 系統(tǒng)間采用松耦合的通訊和開發(fā)方式，例如HTTP+JSON。而非緊耦合的通訊和開發(fā)方式，例如共享接口文件的RPC類框架。
3. A團隊與B團隊間存在明顯的溝通邊界，但二者均可控（可采用統(tǒng)一實踐并堅持）。
4. 提供者提供的接口被多個消費者消費，需要快速反饋代碼變更所造成的影響。

前置知識與能力

• 自動化測試基礎
  • 單元測試
  • 集成測試
  • 端到端測試
• 測試替身
• 簡單設計（增量式設計）/ 測試驅動開發(fā)
• API測試方法
• 版本控制
• 持續(xù)集成 / 持續(xù)交付
• 微服務

可用工具

• Pact（推薦）
  • 消費者驅動
  • Pact Specification 契約規(guī)范 + 多技術棧實現(xiàn)
  • 基于JSON的契約文件
  • 支持HTTP+JSON的接口實現(xiàn) / 消息隊列
• Spring Cloud Contract
  • 提供者驅動 / 消費者驅動
  • JVM + Spring 技術棧，可與Pact Broker集成
  • 基于JAR的契約文件
  • 支持HTTP+JSON的接口實現(xiàn) / 消息隊列