原文連結
https://codefresh.io/docker-tutorial/how-to-test-microservice-integration-with-pact/

挑戰：微服務整合測試

遷移到微服務對測試我們的系統產生了新的挑戰。理論上每個微服務都應該是隔離的並可以獨立操作。但在實踐中一個服務如果沒有其他部分通常沒什麼用。另一方面 - 為一個服務拉起整個系統的拓撲進行測試抵消了微服務期望帶來的模組化和封裝。

挑戰在於如何檢驗與其他服務整合後沒有問題。我們希望越早越好。而且我們不想將複雜的生產環境重現一遍。一般來說這種檢驗是整合功能測試或叫端到端測試。但實際是當我們的系統越來越複雜 - 端到端帶來的收益越少。 大量的相互依賴導致誤報和很長的執行週期。 使得測試變得很難管理與除錯。

這甚至有一個測試金字塔理論（最初由Mike Cohn在他的著作‘Succeeding with Agile’中提到）講述了為了優化你的投入，你需要更少的高層次的端到端測試，寫更多的低層次的單元測試。

請閱讀本文並看看Codefresh(https://codefresh.io/codefresh-signup/?utm_source=Blog&utm_medium=Post&utm_campaign=pactT)， 他是對於Docker最好的CI。

---

單元測試很好！但在它帶來的所有收益中 - 他們對測試與其他服務的整合沒什麼作用。

那我們怎樣保證每個服務團隊可以獨立的迭代但又能保證整體系統的健康呢？我們如何實現持續交付，小批量生產，快速反饋，而又不會在每次變更時引起服務出問題呢？

一個可能的答案是Consumer-Driven Contract(CDC) 測試。這種測試策略是基於一種多年前就定義的服務進化模式。它現在分散式系統變得更常見後變得更適合了。

Consumer-Driven Contracts：

我嘗試簡單解釋一下。 Consumer-Driven Contracts實際就是面向服務與服務關係的合約。意思就是不想以前是provider提供方定義介面與服務級別是什麼樣(同事消費者consumer儘量適配) - 現在消費者來領舞。 每個消費者來定義它期望服務提供方需要交付與需要檢查的。這就將整合的責任轉移到服務提供方。

那就變成以下流程：

在商務合約上者通常描述成‘將消費者放在第一位’ 或‘傾聽你的客戶’。因為想要提供最好的服務我們需要儘量做到客戶期望和需要的。而不是我們假設對的事。

當討論微服務進化時 - 在那種每個服務都有一個獨立團隊開發的大型企業裡尤其重要。有時這些團隊也可能在不同的地理位置和區域。這影響了即時溝通和讓業務功能進化更有挑戰性。

合約測試框架

消費者驅動合約當然可以通過投資團隊間的溝通與協作來管理。 也可以通過使用結構化的系列化格式如protobuf，thrift或messagepack訊息體來解決。但如果要管理一個定義好的流程 - 最好使用框架，尤其如果是個開源的。

這種框架已經出現了。這其中最傑出和活躍的是Pact和Spring Cloud Contract。後者只針對使用JVM的專案。 而Pact使用Ruby寫的但可以支援很多語言，包括Java，Go，Python，Javascript。 讓它很適合在複雜，多樣性的微服務系統中使用。

今天我們會看看如何在兩個服務間定義和校驗合約。消費者服務是用Python寫的。而提供方服務是用Go寫的。測試會在我們的CI/CD流程中進行 - 也就是在Codefresh流水線裡面。

Pact

所以，Pact怎麼工作的？它開始於消費者。

消費者服務的開發寫一個測試。測試定義了與提供方的整合。這包括了提供方需要的狀態，請求的訊息體和期望的結果。基於這個定義Pact建立和執行一個提供方的樁來進行測試。這個測試的輸出回事一個或多個json檔案，一般是這樣的：

{
  "consumer": {
    "name": "billy"
  },
  "provider": {
    "name": "bobby"
  },
  "interactions": [
    {
      "description": "My test",
      "providerState": "User billy exists",
      "request": {
        "method": "POST",
        "path": "/users/login",
        "headers": {
          "Content-Type": "application/json",
        },
        "body": {
          "username":"billy",
          "password":"issilly"
        }
      },
      "response": {
        "status": 200,
      }
    },
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

這就是合約，這就是pact。 現在他們被傳給服務提供方。也可以被提交給共享的git倉庫，或通過Pact Broker應用上傳到共享的檔案儲存。

一旦合約更新過了 - 提供方需要對其進行測試驗證是否仍符合要求。它通過使用共享的pact檔案執行它自己的校驗測試而不是真實版本的服務。如果所有的互動是符合預期的並測試通過了 - 我們就可以繼續了。 如果不 - 提供方的開發需要通知消費方的開發。然後，他們可以一起分析什麼導致了合約的失敗。

本文來自微信公眾號「麥芽麵包，id「darkjune_think」
轉載請註明。微信掃一掃關注公眾號。
交流Email: [email protected]

相關推薦