契約測試Pact實踐

契約測試開發總覽

• 為什麼要使用契約測試（Pact）

  #####目前開發過程中存在的問題
      聯調成本過高,要雙方開發到某一階段後放在同一個環境上才能進行，要同時把握雙方的進度，造成資源和時間上的浪費。
      對於介面的變動把控相當困難。由於介面變動是普遍存在的，尤其對於呼叫關係複雜的介面，一旦發生變動，如果沒有一套機制進行控制，驗證的成本巨大。更不必說持續整合了，只能成為空談。
  
  #####契約測試能給我們帶來什麼
      通過使用契約測試，介面呼叫雙方協商介面後就可以並行開發，並且在開發過程中就利用契約進行預整合測試，不用等到聯調再來整合拉通介面，一旦成熟，在保證質量的前提下，聯調的成本可以減低到幾乎為0。
      因為契約的存在，讓介面的變動有跡可循，即使變動也可以確保變動的安全性和準確性。
      與CI的整合是這一整套流程的關鍵，我們在構建的過程中來完成介面的聯調測試，介面變動的驗證測試。如果規範整個的開發流程，正確使用契約測試，就可以真正實現持續整合，來達到任何時候構建出來的程式都是真正可釋出的狀態。
      Pact工具非常的輕量化，易使用，學習成本低，帶來的效果顯著。
  

• Pact 介紹

• Pact 開發術語

  Consumer：微服務介面的呼叫者

Provider：微服務介面的提供者
契約：是由consumer端和provider端共同定義的介面規範，包括介面訪問的路徑，輸入和輸出資料。在具體的實施中，是由consumer端生成的一個json檔案，並存放在pact broker上
Pact Broker:儲存契約檔案的伺服器

• Pact 開發流程

  **一**.**制定契約**
  制定契約就是雙方定義介面的過程，完成介面文件的編寫。
  **二**.**介面雙方的命名**
  
  這裡的命名在後續寫測試用例的時候需要使用
  **三**.**程式碼實現**
  
  **四**.**構建過程**
  Maven構建的過程會跑測試用例，所以可以自動完成契約檔案的生成，上傳broker，契約檔案的驗證等一系列過程
  這裡要先構建consumer，用來確保先生成契約檔案，以免provider的驗證的時候取不到。
  provider構建時，會啟動真實的服務來進行驗證。
  完成各自構建，聯調在出包的時候就已經完成，意味著構建後出的包就基本是一個可釋出的狀態。