使用 Spring Cloud Contract 實踐事件驅動的微服務契約測試

演講題目：使用 Spring Cloud Contract 實踐事件驅動的微服務契約測試

基本資料

欄位	內容
Conference	COSCUP
年份	2025
日期	2025-08-10
時間	11:00–11:30
地點	國立台灣科技大學
演講題目	使用 Spring Cloud Contract 實踐事件驅動的微服務契約測試
講者	Chris、Samson
狀態	`delivered`
官方連結	COSCUP 2025 議程頁
簡報連結	Google Drive
錄影連結	YouTube

演講摘要

這場分享從事件驅動架構與微服務整合的實際問題出發，介紹如何使用 Spring Cloud Contract 定義並驗證服務之間的事件契約。內容涵蓋 Producer 與 Consumer 的測試流程、REST 與 Kafka 契約測試的差異，以及如何透過自動產生測試與 Stub，提早發現事件格式或服務互動的不相容問題。

演講內容

大綱

問題場景與現況：為什麼微服務間的整合測試複雜、昂貴又容易脆弱。
概念導入：事件驅動架構、契約測試與 Consumer-Driven Contract（CDC）。
Spring Cloud Contract：Producer、Consumer、契約 DSL 與 Stub 的基本概念。
實作展示：以 Food Ordering System 為例，比較 REST 與 Kafka 契約測試流程。
架構與流程：契約定義、Producer 驗證、Consumer 觸發事件與結果確認。
常見錯誤與排除：測試環境、Stub JAR、Kafka 訊息驗證與 Consumer 收訊問題。
契約文化與展望：如何把契約測試納入團隊協作與 CI/CD 流程。
Q&A 與補充資源。

演講重點

微服務解耦後，團隊需要更清楚的溝通契約：事件驅動架構讓服務可以獨立部署與演進，但也把 API 或事件格式的責任邊界變得更重要。若 Producer 與 Consumer 對欄位、事件名稱或資料格式的理解不同，問題通常要到執行時才會被發現。
契約測試補上單元測試與整合測試之間的空隙：不需要每次都啟動完整的微服務環境，就能驗證服務之間約定的輸入與輸出，降低大型整合測試的成本與不穩定性。
Producer 與 Consumer 各自驗證不同責任：Producer 確認自己發布的 API 或事件符合契約；Consumer 則使用契約產生的 Stub，確認自己的服務能正確處理符合契約的輸入。
Kafka 事件測試不能直接套用 REST 測試思維：HTTP 有明確的請求與回應，Kafka 則需要處理事件發布、訊息攔截、Topic、Consumer Group 與非同步處理等問題。
契約要進入日常開發流程：契約不應該只是一份測試設定，而是 Producer 與 Consumer 共同討論介面、審查變更，並在 CI/CD 中持續驗證的協作邊界。

內容整理

這場分享以一個 Food Ordering System 為例，說明 Order Service 建立訂單後發布 OrderCreated 事件，Payment Service 再消費這個事件的完整測試流程。

Producer 端先使用 Spring Cloud Contract 的 DSL 定義事件契約，包括 Topic、事件內容、標頭與欄位格式。執行建置時，框架會根據契約產生測試，觸發 Order Service 發布事件，再驗證實際訊息是否符合約定。由於 Kafka 不是傳統的 HTTP 服務，測試環境還需要準備訊息驗證機制，攔截並提供事件給 Contract Verifier 比對。

Consumer 端則載入 Producer 產生的 Stub JAR，透過契約中設定的觸發標籤送出測試事件，讓 Payment Service 在測試環境中接收。測試最後確認 Consumer 是否完成預期處理，例如建立付款資料或執行相應的業務邏輯。

實作時的注意事項

Producer 與 Consumer 使用的 Topic、事件名稱與欄位格式必須保持一致。
Stub 觸發時使用的 label 必須和契約定義完全相同，包含大小寫。
Kafka 測試環境可以使用 Testcontainers 或 Embedded Kafka，但 Consumer Group 與 offset 需要隔離，避免測試互相影響。
契約不能寫得過度寬鬆，否則測不到真正的相容性問題；也不能把時間戳等動態值硬編碼，造成不必要的失敗。
Spring Cloud Contract 可以降低服務整合風險，但仍需要團隊共同維護契約，並把測試納入 CI/CD 品質門檻。