Test-Double on Tarragon

Semantic Fake Backend（語意級假後端）

Fri, 17 Jul 2026 00:00:00 +0800

語意級假後端是一個持有狀態、只固化已證實後端行為的測試假件：多個前端服務對它走完整的互動鏈，每個操作演變它內部的狀態。在 test double 分類中它對應 Fowler 定義的 fake（有狀態、可運作的簡化實作），「語意級」限定的是行為出處——每一條行為都經過實測證實。它是流程測試的地基，與真實後端驗證測試配對運作。

概念位置

與「由測試餵資料的 stub」的分界有兩條：狀態的歸屬（stub 的回應由測試作者逐條寫死，假後端自己持有狀態並隨操作演變）、行為的出處（stub 回放作者對後端的假設，假後端只收錄實測證實的後端行為）。它與 mock 遮蔽批評的「讓 mock 更逼真」處在相異層次：假後端的模擬止於應用層行為，協議層仍歸 protocol integration test。

可觀察訊號與例子

多個前端服務對同一份後端狀態接力，且出現過「對後端行為假設錯誤」型的漏網 bug。典型例：後端合併資料時重建全部子項並更換 id，前端依賴凍結參照的錯誤在 stub 上永遠測不紅（T.C5）。

設計責任

假後端要決定掛載接縫（in-process 假實作或本地假 server）、行為取證方式、與配對慣例——每一條行為假設對應一條真實後端驗證斷言。掛載判準、取證選單與成本量級的推導在語意級假後端與流程測試章。

Stub

Mon, 20 Jul 2026 00:00:00 +0800

Stub 是測試作者手動寫死回應資料的 test double：呼叫者拿到的每一筆資料，都是測試在建置階段逐條餵進去的固定值。它跟語意級假後端的分野在狀態的歸屬——stub 的回應由測試作者寫死，假後端自己持有狀態、隨操作演變。Stub 回放的是測試作者對後端行為的假設，假設錯了，測試照樣綠燈，這是它的結構性限制，不是實作疏忽。

概念位置

Stub 驗證的標的是「假設成立時、前端邏輯是否正確」，不是「假設本身是否成立」。假設與斷言出自同一人之手，永遠自洽——這一點讓 stub 沒有能力檢出「對後端行為的理解本身就錯了」這一類 bug。Mock 遮蔽描述的是協議層的結構性盲區，stub 的盲區發生在更上游：連需要驗證的行為假設都由同一人設計。兩種盲區疊加時，測試綠燈能證明的範圍比表面上小得多。Stub 在 test double 家族裡的位置（跟 dummy / spy / mock / fake 的分工全景）見 Test Double Taxonomy。

可觀察訊號與例子

辨識訊號是「stub 資料與斷言預期出自同一次測試撰寫」——沒有獨立於測試作者的行為出處。典型案例：前端把後端資料的 id 凍結在本地記錄裡，單元測試建立記錄時順手把對應資料餵進 stub，凍結 id 與 stub 資料恆常一致；真實世界裡讓 id 失效的是後端的合併操作，stub 沒有這個行為，於是「id 失效」這個狀態在測試裡永遠不會出現，功能全壞、測試全綠（T.C5）。

設計責任

判斷「stub 夠不夠」的問句是：如果把 stub 換成真實服務，斷言結果會不會改變？只驗證程式碼內部邏輯（狀態機轉換、錯誤處理分支）時，stub 夠用；驗證對象是「對後端行為的假設」本身時，stub 結構上驗證不出來，需要換成持有狀態、行為有實測出處的語意級假後端。凡是前端持有後端 id 的地方，都要追問後端的哪些操作會讓這個 id 死亡，並把「id 失效」的劇本納入測試範圍——見凍結參照與活解析。

Test Double Taxonomy（Fowler 分類）

Mon, 20 Jul 2026 00:00:00 +0800

Test double 是所有「用來取代真實依賴」的測試替身的統稱，Martin Fowler 把它拆成五種角色：dummy（只填參數位置、從不被實際使用）、stub（測試作者寫死固定回應）、spy（記錄呼叫過程、供事後檢查）、mock（預先設定期望、呼叫不符期望即失敗）、fake（有狀態、可運作的簡化實作）。五種角色的分野在「資料從哪裡來」與「驗證的是狀態還是互動」，不是隨口互換的同義詞。

概念位置

本模組已經在用三種角色、只是沒有集中命名：mock 遮蔽討論的 mock，忠實模擬 API 層的方法簽名與參數型別，驗證呼叫是否符合預期介面；stub是測試作者逐條寫死的固定回應，驗證「假設成立時」邏輯是否正確；語意級假後端對應 fake——有狀態、可運作、模擬已證實後端行為的簡化實作。三者的差異不是實作細節，是各自能檢出的 bug 類型不同：mock 檢出介面誤用，stub 檢不出假設本身的錯誤，fake 能讓假設在多服務接力中被真正驗證。

可觀察訊號與例子

判斷一段程式碼裡的替身屬於哪個角色，看兩件事：資料是不是每條測試手動寫死的（是 → stub 或 dummy，取決於有沒有被實際讀取）、驗證是斷言最終狀態還是斷言呼叫發生過（前者偏 stub/fake，後者偏 spy/mock）。混用角色而不自知的訊號是：團隊說「這裡有 mock」，但程式碼裡是逐條寫死回應、沒有設定呼叫期望——用詞是 mock、行為是 stub，兩者的可測範圍不同，混用會讓覆蓋率的認知跟實際脫節。

設計責任

選角色的判準是「要驗證什麼」：只驗證程式碼內部邏輯、不涉及外部行為假設 → stub 或 dummy 就夠；要驗證「呼叫方式是否符合介面契約」→ mock；要驗證「假設成立時的多服務接力行為」，且假設本身有實測出處 → fake。角色選錯的典型後果是凍結參照與活解析描述的那類盲區——用 stub 的地方假設會變、卻用了固定回應，狀態變化不會在測試裡發生。跨層盲區（協議層、假設層）疊加時，測試綠燈能證明的範圍比表面上薄。