如何用Pact進行微服務集成測試

原文連接
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: zhukunrong@yeah.net