目錄
- 前言
- 1. 撰寫集成測驗
- 1.1 服務通常與其他服務互動
- 1.2 集成測驗的策略
- 1.3 針對持久化層的集成測驗
- 1.4 針對基于REST的請求 / 回應式互動的集成測驗
- 1.5 針對發布 / 訂閱式互動的集成測驗
- 1.6 針對異步請求 / 回應式互動的集成契約測驗
- 2. 撰寫組件測驗
- 2.1 定義驗收測驗
- 2.2 使用Gherkin撰寫驗收測驗
- 2.2.1 使用Gherkin定義驗收測驗
- 2.2.2 使用Cucumber執行規范
- 2.3 設計組件測驗
- 2.4 為FTGO的Order Service撰寫組件測驗
- 2.4.1 Order Service的組件測驗設計
- 2.4.2 OrderServiceComponentTestStepDefinitions類
- 2.4.3 運行組件測驗
- 3. 端到端測驗
- 3.1 設計端到端測驗
- 3.2 撰寫端到端測驗
- 3.3 運行端到端測驗
- 4. 本章小結
- 最后
前言
本章介紹集成測驗、組件測驗與端到端測驗；
這是一本關于微服務架構設計方面的書，這是本人閱讀的學習筆記，以下對一些符號做些說明：
（）為補充，一般是書本里的內容；
[]符號為筆者筆注；
1. 撰寫集成測驗
集成測驗驗證服務是否可以與其客戶端和依賴關系進行通信；
1.1 服務通常與其他服務互動
測驗服務間的互動方法：
- 端到端測驗：啟動所有服務并通過其API進行測驗；
- 集成測驗：不啟動服務，可以通過一些策略簡化測驗；
1.2 集成測驗的策略
集成測驗的兩種策略：
- 第一種：測驗每個服務的配接器，以及可能的配接器支持類，如JPA持久化測驗；
- 第二種：使用契約，契約是一對服務之間互動的具體實體；契約的結構取決于服務之間的互動型別；
- 實作契約的方法取決于測驗消費者還是提供者：
- 消費者端測驗：用于消費者配接器的測驗，它們使用契約來配置樁，以此模擬提供者程式的行為，使你能夠直接運行測驗，而不需要運行消費者對應的提供者程式；
- 提供者端測驗：用于提供者配接器的測驗，它們使用契約來測驗配接器，使用模擬來滿足配接器的依賴關系；
1.3 針對持久化層的集成測驗
持久化集成測驗每個階段的行為：
- 設定：通過創建資料庫結構設定資料庫，并將其初始化為已知狀態，也可能開始執行一些必要的資料庫事務；
- 執行：執行資料庫操作；
- 驗證：對資料庫的狀態和從資料庫中檢索的物件進行斷言；
- 驗證：對資料庫的狀態和從資料庫中檢索的物件進行斷言；
- 拆解：可選階段，可以撤銷對資料庫所做的更改，如回滾在設定階段提交的事務；
1.4 針對基于REST的請求 / 回應式互動的集成測驗
圖解：
- 消費者端：消費者端的API Gateway集成測驗會使用契約來配置一個模擬Order Service行為的HTTP樁服務器；
- 圖示的WireMock是一個有效模擬HTTP服務器的工具；
- 提供者端：Spring Cloud Contract 使用契約來生成提供者端Order Service集成測驗代碼，該測驗使用Spring Cloud MVC 或 Rest Assured Mock MVC測驗控制器；
- 這里的測驗代碼在HttpTest測驗類中；
- 契約：契約中的請求內容指定了從API Gateway發出的HTTP請求；契約的回應指定了樁向API Gateway發送回的回應；
- 該契約描述了API Gateway成功從Order Service檢索Order的嘗試；
- 該測驗將驗證Order Service的API是否滿足消費者的期望；
- 該測驗驗證是否符合契約；
1.5 針對發布 / 訂閱式互動的集成測驗
- OrderCreated事件的契約指定時間的通道，以及預期的訊息主體和頭部；
- 契約中有另外兩個重要元素：
- label：用于消費者測驗，觸發Spring Contact發布事件；
- triggeredBy：生成的測驗方法呼叫的超類方法的名稱，用于觸發事件的發布；
- 其驗證負責發布Order聚合領域事件的OrderDomainEventPublisher是否發布了符合客戶期望的事件；
- OrderHistoryEventHandlers類的事件處理程式呼叫OrderHistoryDao來更新CQRS視圖；
- 每個測驗方法首先呼叫Spring Cloud來發布契約中定義的事件，然后驗證OrderHistoryEventHandlers是否正確呼叫了OrderHistoryDao；
1.6 針對異步請求 / 回應式互動的集成契約測驗
圖解：
- 消費者端：消費者端測驗驗證命令訊息代理類是否發送了結構正確的命令訊息，并正確處理回復訊息；
- 在本例中，KitchenServiceProxyTest測驗KitchenServiceProxy；
- 其使用Spring Cloud Contract配置訊息樁，驗證命令訊息是否與契約的輸入訊息匹配，并使用相應的輸出訊息進行回復；
- 提供者端：提供者端測驗由Spring Cloud Contract代碼生成，每種測驗方法對應一份契約；
- 提供者端測驗方法將契約的輸入訊息作為命令訊息發送，并驗證回復訊息是否與契約的輸出訊息匹配；
- 契約：需要就命令式訊息通道的名稱以及命令和回復訊息的結構達成一致；與REST互動方式不同的是，命令的契約指定輸入訊息和輸出訊息，而不是HTTP請求和回復；
- 此互動契約由輸入訊息和輸出訊息組成；
- 這兩條訊息都指定了訊息通道、訊息主體和訊息頭部；命名約定來自提供者的角度；
- 輸入訊息是發送到KitchenService通道的CreateTicket命令；輸入訊息的messageFrom元素指定從中讀取訊息的通道；
- 輸出訊息是一個成功的回復，發送到CreateOrderSaga的回復通道；輸出訊息的sentTo元素指定應該將回復發送到的通道；
- 該測驗呼叫服務的訊息代理，并從兩個方面驗證其行為；
- 首先驗證訊息代理發送的是否符合契約的命令訊息；
- 其次驗證代理是否正確地處理回復訊息；
- 提供者端集成測驗必須通過發送回復來驗證提供者是否正確處理了命令訊息；
- Spring Cloud Contract生成的測驗類具有針對每個契約的測驗方法；
- 每個測驗方法都會發送契約的輸入訊息，并驗證回復是否與契約的輸出訊息相匹配；
2. 撰寫組件測驗
服務組件測驗模式：單獨測驗服務；
組件測驗單獨驗證服務的行為，使用模擬其行為的樁代替服務的依賴關系；
2.1 定義驗收測驗
- 驗收測驗是針對軟體組件的面向業務的測驗；
- 驗收測驗從組件客戶端而不是內部實作的角度描述了所需的外部可見行為；
- 測驗源自用戶故事或用例；
2.2 使用Gherkin撰寫驗收測驗
使用Java撰寫驗收測驗具有挑戰性，更好的方法是消除手動轉換步驟并撰寫可執行的場景；
Gherkin用于撰寫可執行規范的DSL；使用Gherkin可以使用類似英語場景定義驗收測驗，然后使用Cucumber執行規范；
2.2.1 使用Gherkin定義驗收測驗
圖解：
- Gherkin規范提供一系列功能，每個功能都有一組場景描述，場景具有given-when-then結構：
- given：先決條件；
- when：發生的動作或事件；
- then / and：預期的結果；
- 圖示代碼是Place Order功能的部分代碼，功能包括幾個元素：
- 名稱：對于此功能，名稱為Place Order；
- 規范簡介：描述該功能存在的原因，對于此功能，規范簡介是用戶故事；
- 場景：Order authorized 和 Order rejected due to expired credit card；
- 用戶在第一個場景成功；第二個失敗，因為信用卡過期；
2.2.2 使用Cucumber執行規范
圖解：
- Cucumber是一個自動化框架，用于執行Gherkin撰寫的測驗場景；其有多種語言實作方式；
- 使用 Cucumber for Java 時，可以撰寫步驟自定義類，如上述代碼所示；
- 注解的值元素是一個正則運算式，Cucumber與步驟匹配；
- @Given：設定階段；
- @When：執行階段；
- @Then 和 @And：驗證階段；
2.3 設計組件測驗
為了避免為多個服務配置樁，設定資料庫和訊息傳遞基礎設施；
- 行程內組件測驗：
- 行程內組件測驗使用常駐記憶體的樁和模擬代替其依賴性來運行服務；
- 如：使用@SpringBootTest來為Spring Boot應用測驗；
- 好處是撰寫簡單，速度快；缺點是不測驗服務的可部署性；
- 行程外組件測驗：
- 行程外組件測驗使用真實的基礎設施服務，但對應用程式服務的任何依賴項使用樁；
- 好處是提高測驗覆寫率；缺點是撰寫復雜、執行速度慢；可能比行程內組件測驗脆弱；
- 如何為行程外組件測驗撰寫樁服務：
- 被測服務通常使用涉及發回回應的互動方式來呼叫依賴項；
- 行程外測驗必須為這些型別的依賴項配置樁，這些依賴項處理請求并發回回復；
- 可以使用Spring Cloud Contract；更簡單的選擇是在測驗內部部署樁；
2.4 為FTGO的Order Service撰寫組件測驗
Order Service的組件測驗，使用行程外策略來測驗作為Docker容器運行的服務；
2.4.1 Order Service的組件測驗設計
圖解：
- 幾個注解的含義：
- @CucumberOptions：指定在哪可以找到Gherkin功能檔案；
- @RunWith(Cucumber.class)：告訴JUNIT使用Cucumber測驗運行器；
- @RunWith注解通過讀取Gherkin功能定義測驗，并使用OrderServiceComponentTestStepDefinitions類使它們可執行；
- OrderServiceComponentTestStepDefinitions類是測驗核心，它使用@ContextConfiguration注解，創建了Spring ApplicationContext；
- Spring ApplicationContext定義了各種Spring組件，包括訊息樁等；
2.4.2 OrderServiceComponentTestStepDefinitions類
- 此方法使用SagaParticipantStubManager測驗輔助類，為Saga參與方構造樁；
- 此方法定義了
When I place an order for Chicken Vindaloo at Ajanta這一步驟；
- 該方法定義
Then the order should be ...步驟的含義，驗證Order是否已成功創建并且處于預期狀態；
- 該方法定義了
And an event should be published步驟，驗證預期的領域事件是否已發布；
2.4.3 運行組件測驗
圖解：
- 測驗使用Docker來運行Order Service及其依賴項；
- 前面Gradle做了兩件事：
- 將Gradle Docker Compose插件配置為在組件測驗之前運行，并啟動Order Service及其它配置為依賴的基礎設施服務；
- 將componentTest配置為依賴于assemble，以便首先構建Docker映像所需的JAR檔案；
- 做完兩件事后，用
./gradlew :ftgo-order-service:componentTest命令運行這些組件測驗；該命令做了以下操作：- 構建Order Service；
- 運行服務及其基礎設施服務；
- 運行測驗；
- 停止正在運行的服務；
3. 端到端測驗
端到端測驗位于測驗金字塔頂端，會測驗整個應用程式；
- 端到端測驗的缺點：開發緩慢、脆弱且耗時；
3.1 設計端到端測驗
- 需要控制端到端測驗數量；
- 可以使用用戶旅程測驗策略，將幾個關聯的測驗撰寫成一個單一測驗；
3.2 撰寫端到端測驗
圖解：
- 面向業務的測驗，寫在業務人員理解的DSL中；
- 與驗收測驗的區別在于，有多個動作而不是單一的Then；
3.3 運行端到端測驗
- 端到端測驗必須運行整個應用程式，包括任何所需的基礎設施服務；
- 可以使用Gradle Docker Compose插件運行所有應用程式的服務；
4. 本章小結
- 使用契約作為示例訊息來驅動服務之間互動的測驗，撰寫測驗以驗證兩個服務的配接器是否符合契約，而不是撰寫運行兩個服務及其傳遞依賴關系的慢速測驗；
- 撰寫組件測驗以通過其API驗證服務的行為，應該通過單獨測驗服務來簡化和加速組件測驗，使用樁來解決其依賴項；
- 撰寫用戶旅程測驗，以最大限度地減少端到端測驗的數量，這些測驗緩慢、脆弱又耗時，用戶旅程測驗模擬用戶在應用程式中的旅程，并驗證相對較大的應用程式功能片段的高級行為，因為測驗很少，所以每次測驗開銷的數量（如測驗設定）被最小化，這就加快了測驗速度；
最后
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/303782.html
標籤：架構設計