契約測試：解決微服務(wù)測試的問題
FROM https://blog.csdn.net/crisschan/article/details/88310201
為什么是契約測試
契約測試（ContractTest）第一次看到我是在Martin Fowler的文章里。（原文在這里感興趣的可以去看看https://martinfowler.com/bliki/ContractTest.html）
在他的這篇文章了，首先說了一下TestDouble的劣勢椎扬，其中TestDouble（對這個定義感興趣可以見https://martinfowler.com/bliki/TestDouble.html）
其實我們也很少提及。為了解釋契約測試遂跟，我們在本文吧TestDouble替換成MOCK，這也行并不正確，但是可以快速讓我們理解。
MOCK服務(wù)相信很多人都知道主要是用了幫助解決外部依賴而存在的纤控。在兩個團隊分別負責(zé)Service1和Service2的開發(fā)，其中Service1調(diào)用Service2碉纺。在測試過程中很容易由于Service1和Service2之間網(wǎng)絡(luò)速度、服務(wù)不穩(wěn)定等問題導(dǎo)致的無法測試Service1刻撒，那么這個時候我們很多人第一個想到的是Service2用MOCK服務(wù)替代掉骨田。這也確實是一個行之有效的方法。
但是現(xiàn)在開發(fā)周期声怔、迭代周期和迭代頻率都在變短态贤、變快，如果Service1在開發(fā)或者測試的使用應(yīng)用了Service2的MOCK服務(wù)醋火，同時Service2也被自己的Own團隊進行了升級迭代悠汽，但是Service1調(diào)用的MOCK服務(wù)沒有升級，這就導(dǎo)致了集成測試的時候才能發(fā)現(xiàn)兩邊不一致的問題芥驳，這將大大影響項目或者迭代周期的進度柿冲。
在微服務(wù)大行其道的今天，各種服務(wù)接口（provider）又被各種服務(wù)調(diào)用（comsumer）兆旬，生產(chǎn)者消費者模式就促生了契約測試（更應(yīng)該叫消費者驅(qū)動的契約測試假抄，Cunsumer-Driven Contracts，簡稱CDC）丽猬，CDC就是從消費者的角度定義測試宿饱，通過給API提供方提供契約的形式，來完成功能的實現(xiàn)脚祟。當(dāng)今比較主流的CDC測試框架有PACT（https://github.com/pact-foundation/pact-specification）
cdc核心原則(轉(zhuǎn)自：https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html）:
cdc是以消費者提出接口契約谬以，交由服務(wù)提供方實現(xiàn)，并以測試用例對契約進行產(chǎn)生約束由桌，所以服務(wù)提供方在滿足測試用例的情況下可以自行更改接口或架構(gòu)實現(xiàn)而不影響消費者为黎。
cdc是一種針對外部服務(wù)的接口進行的測試邮丰，它能夠驗證服務(wù)是否滿足消費方期待的契約。 它的本質(zhì)是從利益相關(guān)者的目標(biāo)和動機出發(fā)碍舍，最大限度地滿足需求方的業(yè)務(wù)價值實現(xiàn)柠座。
Pact的契約測試流程
如上圖，使用Pact完成契約測試后片橡，首先我們還是按照原來的測試用例對Consumer進行測試妈经，在需要Consumer和Provider發(fā)生交互的時候，Provider被替換成和Pact交互捧书。在測試過程中吹泡，Pact會記錄下全部的Provider的調(diào)用請求（保存在一個Json文件中），這就是消費者的契約经瓷。如果在執(zhí)行Provider的測試的時候爆哑，就不需要從新完成Provider的測試用例，只需將Pact記錄下來的消費者契約作為測試的輸入舆吮，完成和Provider的交互揭朝，來驗證Provider是否滿足了消費者契約。
這也說明了契約測試既不是單元測試也不是集成測試色冀，是出于單元測試和集成測試之間的一層測試行為潭袱。
Pact官方給出的幾個場景：
（轉(zhuǎn)自： https://insights.thoughtworks.cn/about-contract-test/）
適用場景：
團隊能把控開發(fā)過程中的Consumer和Provider端
適合Consumer驅(qū)動開發(fā)的場景
對于每個獨立的Consumer端，Provider端都能管理好需求锋恬。
不適用的場景：
公共API或者是OAuth授權(quán)服務(wù)
Provider端和Consumer端沒有良好的溝通渠道
針對性能的測試
Provider端的功能性測試（Pact只測試內(nèi)容和請求格式）
對于不同輸入有相同的輸出屯换，并未達到驗證的目的
當(dāng)前測試輸入需要依賴之前測試返回的結(jié)果
參考
https://www.cnblogs.com/jinjiangongzuoshi/p/7815243.html
http://aleung.github.io/blog/2017/06/21/pact/
https://insights.thoughtworks.cn/about-contract-test/
關(guān)注我，關(guān)注測試
FROM：https://blog.csdn.net/crisschan
