測試金字塔模型
測試是軟件流程中非常重要，不可或缺的一個環節。一般的測試分為單元測試，集成測試，端到端的手工測試，這也是構成測試金字塔的三個層級。我們今天將要討論的話題是契約測試，它是處於單元測試和集成測試中間的一個環節。這三個層級分別測試的場景如下：
- 單元測試：測試單個service
- 集成測試：測試由多個services組成的系統
- 端到端測試：測試從用戶到各個外部系統的整個場景
什么是契約測試？
契約測試最開始的概念由Martin Fowler 提出，請參見這篇文章， 它又被稱之為：消費者驅動的契約測試（Consumer Driven Contracts）。這里的契約是指軟件系統中各個服務間交互的數據標准格式，更多的指消費端（client）和提供端（server）之間交互的數據接口的格式。
為什么要存在契約測試？
系統工程中存在這樣的理論：線性系統（即復雜性隨規模線性增長的系統）的可靠性等於組成它的各個組件的可靠性之乘積。這容易理解，因為整個系統正常工作的條件是必須每個組件都同時正常工作。
如上圖所述，三個組件共同支撐的系統，如果每個組件的可靠性是90%，那么整個系統的可靠性就是 90%×90%×90%=72.9%，我們可以看到系統整體的可靠度是低於任一組件的可靠性的。如果一個系統由100個組件組成，每個組件即使能達到99%的可靠性，那么整個系統的可靠性也會降到36.6%左右。
我們常說復雜性是軟件工程的最重要的特性，一個完善的軟件系統必然是靠很多的子系統，組件共同撐起來的。根據上面的理論，如果是一個復雜的軟件系統那么每一個組件的可靠性都對系統整體的可靠性有着非常重要的影響，排除組件本身的可靠性的因素，各個組件之間的相互依賴和調用關系也將會對系統的穩定性有着決定性的影響。隨着業務的復雜度越來越高，整個系統也變得越來越龐大和錯綜復雜，在今天的軟件工程開發中微服務已經不是一個新名詞，在微服務的架構下通常一個client會與多個service相互交互，可以想象一下如果某一個服務的接口發生變化將會影響整個系統的運行。如下圖展示的傳統的大服務與微服務的區別。
那么在微服務模式下如果保證各個服務端與消費端之間以及服務與服務之間能夠可靠的交互呢？這就回到了到我們要聊的契約測試的話題。
如下圖，在服務端接口發生變化的情況下通過契約測試可以很容易的測試出契約不匹配，可以在集成測試之前就能發現問題，盡早解決。
契約測試和單元測試，集成測試，端到端測試區別是什么？
單元測試：
- 通常是測試單個類，方法的可靠性
- 它的價值在於快速的反饋某一個很小的功能點是否能准確的工作
- 通過單元測試能夠更明確的剖析你的實現邏輯
- 如果用TDD的開發模式，能夠做代碼重構以及改善代碼整潔度
集成測試：
- 關注的是各個服務之間交互
- 測試接口連通性和流程的可用性
端到端測試：
- 從用戶的角度驗證整個功能的准確性和可用性
- 測試的是端到端的流程，會加入用戶數據驗證功能是否可用
- 不會關注在某一細小的功能點的實現
- 關注的是整個業務流程，產生的業務價值大
契約測試：
- 測試接口和接口之間的正確性
- 驗證服務層提供的數據是否是消費端所需要的
- 將本來需要在集成測試中體現的問題前移，更早的發現問題
- 更快速的驗證消費端和提供端之間交互的基本正確性
契約測試解決能解決什么問題？
- 可以使得消費端和提供端之間測試解耦，不再需要客戶端和服務端聯調才能發現問題
- 完全由消費者驅動的方式，消費者需要什么數據，服務端就給什么樣的數據，數據契約也是由消費者來定的
- 測試前移，越早的發現問題，保證后續測試的完整性
- 通過契約測試，團隊能以一種離線的方式(不需要消費者、提供者同時在線)，通過契約作為中間的標准，驗證提供者提供的內容是否滿足消費者的期望。
一般契約測試是在單元測試之后，集成測試之前要進行的，首先在保證各自功能正確的前提下測試消費者和提供者的契約是否相匹配，然后再進一步的測試功能的完備性和整個業務流的正確性。
寫在最后
本文主要淺顯的介紹了契約測試是什么以及它的重要性，后續將會繼續介紹契約測試的框架以及相關實踐。