Testing 知識卡片 on Tarragon

Protocol Integration Test

Fri, 19 Jun 2026 00:00:00 +0000

Protocol integration test 的核心概念是「對真實服務實例驗證協議層行為」。它跳過 mock，直接連線到真實的外部服務，觀察連線握手、認證流程、資料編碼和回應格式是否符合協議規格。和 mock 遮蔽互補 — mock 遮蔽的盲區正是 protocol integration test 的驗證範圍。可先對照名義 integration test。

概念位置

Protocol integration test 位在 unit test 和 E2E test 之間。Unit test 用 mock 驗證程式碼邏輯，E2E test 經過 UI 驗證完整流程，protocol integration test 用程式碼直接呼叫 client 端連線函式、對真實服務執行操作。它填補「程式碼邏輯正確但協議互動錯誤」這個 mock 結構性無法覆蓋的空隙。

可觀察訊號與例子

需要 protocol integration test 的訊號是：API 簽名用寬泛型別（dynamic、Object、Any）隱藏了協議層的行為分支、mock 跳過了業務關鍵步驟（認證、握手）、或外部服務對錯誤輸入靜默忽略。WebSocket 的 text/binary frame 差異、gRPC 的 streaming deadline、MQTT 的 QoS level 都是典型場景。

設計責任

Protocol integration test 要決定服務 fixture 的管理方式（Process.start / Docker / testcontainers）、健康檢查策略（port 可達 / HTTP health / 業務操作成功）、和狀態隔離方式（每 test 重啟 / 重設狀態 / 獨立 namespace）。成本判斷依據服務啟動成本和協議複雜度兩個維度。

Mock 遮蔽

Fri, 19 Jun 2026 00:00:00 +0000

Mock 遮蔽的核心概念是「mock 忠實模擬程式語言的 API 契約，但跳過了協議層和環境層的行為差異，讓這些差異在 test 中不可見」。遮蔽是 mock 的設計邊界，遮蔽的範圍形成結構性的驗證盲區。可先對照 protocol integration test 和名義 integration test。

概念位置

Mock 遮蔽發生在 API 層和協議層之間的語意斷裂處。Mock 模擬的是最上層（方法簽名、參數型別、回傳值），真實行為發生在下面兩層（協議語意、執行環境）。遮蔽有兩種模式：功能存在但行為錯誤（mock 接受了真實服務不接受的輸入）、功能根本沒實作（mock 不需要該功能就能通過）。

可觀察訊號與例子

Mock 遮蔽的訊號是：test 全過但實機失敗的 bug 類型集中在外部互動（連線、認證、編碼）、修復後原有 test 不需要改動、bug 修復是型別轉換或編碼調整。FakeWebSocketChannel 的 sink.add(dynamic) 不區分 text/binary frame 是典型案例。

設計責任

面對 mock 遮蔽的正確策略是分層驗證 — mock 負責 API 層，protocol integration test 負責協議層。增加 mock test 數量無法跨越層級盲區。Mock 也不應該模擬協議行為 — 讓 mock 更「逼真」會讓 mock 本身變成需要維護和驗證的複雜元件。

名義 Integration Test

Fri, 19 Jun 2026 00:00:00 +0000

名義 integration test 的核心概念是「test 標題或路徑包含 integration，但所有外部依賴都被 fake 替換，實際驗證的是內部邏輯而非真實服務互動」。它的問題在命名造成的認知偏差 — 團隊以為 integration 已驗證，實際上協議層完全沒被覆蓋。可先對照 mock 遮蔽和 protocol integration test。

概念位置

名義 integration test 在 test 分類中介於 unit test 和真正的 integration test 之間。它的 scope 比 unit test 大（多個內部元件一起測），但驗證對象和 unit test 相同（程式碼內部邏輯）。它和 mock 遮蔽的關係是：名義 integration test 用 mock 替換所有外部依賴，mock 遮蔽了協議層行為，而 test 名稱讓團隊以為這些行為已被驗證。

可觀察訊號與例子

辨識名義 integration test 的三個特徵：核心外部依賴 100% 被 fake 取代、沒有真實的 I/O 操作（網路、檔案、資料庫）、setUp() 不需要啟動外部程序或建立網路連線。

設計責任

修正策略分兩步：改名（讓 test 名稱反映真實驗證對象，如 connection_state_machine_test）和補寫（如果協議互動是關鍵路徑，補寫對真實服務的 protocol integration test）。在 test 檔案頂部標明被 fake 取代的依賴清單，讓後續讀者快速判斷驗證邊界。

Screen State Test

Fri, 19 Jun 2026 00:00:00 +0000

Screen state test 的核心概念是「驗證畫面層級的狀態機是否完整 — 每個狀態下使用者看到什麼、能操作什麼、怎麼離開」。它的斷言對象是使用者可見的畫面，和 unit test（斷言函式回傳值）及 protocol integration test（斷言協議互動）職責不同。可先對照畫面狀態矩陣。

概念位置

Screen state test 是測試三層中的第三層。Unit test 驗證程式碼邏輯，protocol integration test 驗證協議互動，screen state test 驗證畫面狀態。同一段程式碼可能 unit test 通過但 screen state test 失敗 — 因為 UI binding 的問題讓正確的邏輯沒有反映到畫面上。

可觀察訊號與例子

需要 screen state test 的訊號是畫面有多個狀態（loading / connected / error / disconnected）且狀態轉換邏輯複雜。畫面狀態矩陣直接轉成 test case — 矩陣中每個狀態的「顯示」「可用操作」「退出路徑」各對應一個 assertion。

設計責任

Screen state test 要決定用什麼工具驗證畫面（widget test / integration test / Playwright）、斷言的粒度（元素存在 / 文字內容 / 視覺比對）、和狀態的觸發方式（mock 觸發狀態切換 / 真實操作觸發）。