使用Wiremock進行整合測試 - kubilay

• 在Wiremock之前我們如何管理整合測試？
• 是什麼問題促使我們使用Wiremock？
• 我們如何使用Wiremock？

在Wiremock時代之前
我們有2個不同的專案：

• api-gateway：主要的Restful API專案。
• api-gateway-test：使用Gherkin和Java的Cucumber整合測試專案。

那麼，有什麼問題呢？
乍一看，這種情況似乎並不成問題，但讓我提示您幾周（也許幾天）後發生的情況。由於此外部api是階段例項，因此將來相同請求的響應可能會給您一個404驚喜。因為，也許external-api的所有者團隊正在進行DELETE端點測試並感到驚訝，所以他們刪除了我們用來執行測試的訂單資訊。簡而言之，該測試訂單不再存在。這意味著某人必須找到合適的訂單資訊來修復測試。而且該命令在某個時候也不會存在。然後有人去解決。.我想您在這裡看到我的意思，這是一個惡性迴圈，我們需要進行短跑。
這是眼前的問題之一，還有另一個至關重要的問題。假設我們有100％的把握，只要我們想提出相同的請求，就會始終奇蹟般地存在所請求的資訊。超時和響應時間如何？
 

在Wiremock時代之後
首先，讓我們看一下Wiremock官方網站的基本定義：

WireMock是基於HTTP的API的模擬器。有些人可能會認為它是服務虛擬化工具或模擬伺服器。
當您依賴的API不存在或不完整時，它可以使您保持生產力。它支援測試真實API無法可靠生成的極端情況和失敗模式。而且由於速度很快，因此可以將構建時間從數小時縮短到數分鐘。
閱讀定義後，您將意識到這很可能會解決前面提到的問題。它可以模擬所有這些超時失敗案例，還可以為我們正在討論的那些外部api提供模擬響應。
這意味著Wiremock可以等待請求，並透過匹配請求來返回告訴我們要返回的內容，就好像它是我們的任何外部api一樣。
從現在開始，我們的整合測試專案不再負責執行測試。此步驟移至gateway-api專案的管道。現在，對於每個專案，管道的狀態可以總結如下：

• Gateway-api：Git推送->構建專案->將構建的Docker映像作為'gateway-api：latest'推送到Docker登錄檔
• Gateway-test-api：Git推送->構建專案->將構建的Docker映像作為'gateway-api-test：latest'推送到Docker登錄檔

variables:
  REGISTRY_URL: <docker_registry_url>
  REGISTRY_PASS: <docker-registry-username> 
  REGISTRY_HOST: <docker-registry-password>

stages:
  - Integration test
  - Build

Build:
  stage: build
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS $REGISTRY_HOST
    - docker build -t greay-gw-api-build .
    - docker push great-gw-api-build

Integration Test:
  Integration test
  image: $REGISTRY_URL/docker-compose-git
  services:
    - $REGISTRY_URL/docker-dind
  variables:
    DOCKER_HOST: $REGISTRY_URL
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS $REGISTRY_HOST
    - docker-compose up --abort-on-container-exit

• 構建最新的映像並將其推送到指定的登錄檔。
• 如果docker-compose檔案存在於同一目錄中，請執行該檔案。（我們將很快透過示例深入研究此流程。）

• 我們在gateway-api中實現了某種功能，並將其合併到master分支中。合併之後，帶有“：latest”標籤的docker映像將被推送到相應的登錄檔。
• 我們還針對該功能編寫了整合測試，還將其合併到master分支，這再次導致帶有“：latest”標籤的測試專案的docker映像被推送到相應的登錄檔。