"Fake-Backend"
- 流程測試基礎設施
在 Flutter 專案建立流程測試時碰到的 Dart 實作限制：控制器能不能在 headless 環境立起來、binding 怎麼跟真實網路測試共存、測試輸出雜訊怎麼治理、假後端的回應資料走什麼路徑序列化——限制形成一條建置鏈，前一個的答案決定後一個的形態
- Semantic Fake Backend（語意級假後端）
持有狀態、只固化已證實後端行為的測試假件；與由測試餵資料的 stub 以狀態歸屬和行為出處劃界
- T.C5 凍結參照失效被 stub 遮蔽 — 測試全綠、功能全壞
前端把後端資料的 id 凍結在本地記錄裡，後端的合併操作會重建資料、舊 id 全部失效 — 單元測試的 stub 由測試自己餵資料，永遠不會經歷「id 死亡」，bug 存在期間所有測試綠燈
- T.C6 流程測試首跑抓到修復自己引入的順序 bug
單元測試直接把狀態塞進被測物、繞過了真實的資料過濾鏈；流程測試讓資料走完整鏈路，第一次執行就抓到「刷新在列表同步之前」的編排順序錯誤 — 而這個錯誤正是前一個 bug 的修復引入的
- 語意級假後端與流程測試
bug 的成因是對後端行為的假設錯誤、由測試餵資料的 stub 驗證不出來時：建一個持有狀態、模擬已證實後端行為的假後端（test double 分類的 fake），讓流程測試走完整的多服務互動鏈
- T.C7 症狀相同、成因兩種 — 用測試切開前後端責任
刪除單據後資源佔用狀態未還原：可能是後端沒釋放，也可能是後端釋放了但前端沒刷新畫面 — 兩種成因症狀完全相同。假後端模擬兩種行為各寫一條測試、再用真實後端測試一跑定案
- Stub
測試作者手動寫死回應資料的 test double：驗證的是假設成立時邏輯是否正確，假設本身錯誤時無法檢出
- 有狀態假後端用真實模型序列化回應：手寫 JSON fixture 會重踩產品已解決的問題
流程測試的假後端持有 freezed 模型物件、以 toJson 序列化回應，讓服務層走完整的反序列化鏈。對照組是手寫 JSON fixture——同一批測試裡的 raw 寫法重踩了一次產品早已內建處理的分頁包裝，證明「回應形狀的知識」應該只存在一份。