閘門 spike：編排的宿主能不能在 headless 環境立起來

流程測試要驅動的是控制器裡的真實編排——順序約束、防護動作、收尾同步——而 Flutter 的控制器在 onInit 常帶平台耦合（platform channel 訂閱、相機偵測、外接裝置 plugin）。這些耦合在 headless 測試環境全部失效。

開工前先做一條最小測試 spike：能否建構控制器並呼叫編排入口。spike 的答案決定整個套件形態——立得起來就直接驅動真實編排（零漂移），立不起來要先評估重構接縫的成本。

平台耦合的中和工具在 Dart 生態有固定的對應：

時序欄位承載的是這張表最容易踩的陷阱：EventChannel 的訂閱發生在 plugin 建構子裡，晚一步掛 mock，訂閱已經對著真實 channel 成立、之後補掛不會回溯生效——症狀是測試偶發卡在等事件。MethodChannel 的容錯高一些（呼叫當下才查 handler），但同樣要在第一次呼叫前就位。no-op 子類優於 mock 框架的場景：要中和的成員少（覆寫列表一目瞭然）、其餘行為要保留真實。流程測試的精神是假件越少，測試的證言越可信——這裡指的是平台耦合層的假件（與被驗編排無關的雜訊），被測邊界本身的假後端是另一回事，它的設計判準與忠實性把關見語意級假後端。

這套 channel mock 加 no-op 子類的組合（後文稱 harness）一旦成立就收斂為共用 bootstrap 方法——之後每條流程測試的邊際成本只剩劇本本身。完整 case 與程式碼範例：讓 UI 控制器在 headless 測試立起來。

兩種測試的共存：binding 的檔案級 isolate 隔離

流程測試需要 TestWidgetsFlutterBinding（mock channel、立控制器），真實後端驗證測試需要真實網路——兩者互斥。TestWidgetsFlutterBinding.ensureInitialized() 的副作用之一是把 dart:io 的 HttpClient 換成一律回 400 的假件，且這個副作用是程序級全域、沒有乾淨的關閉開關。

共存機制不需要額外設計：flutter test 讓每個測試檔案跑在獨立 isolate，而 isolate 之間記憶體不共享——binding 換掉的全域物件只在自己的 isolate 內生效，副作用因此以檔案為邊界。

硬約束：真實後端驗證測試的檔案不可 import 流程測試的 harness——harness 為了 mock channel 第一步就是 ensureInitialized，import 進來即使不直接呼叫，任何共用 helper 順手初始化都會中招。違反這條約束的症狀是「穩定 400、無網路痕跡」——症狀與原因之間距離太遠，值得寫進檔頭。

真實後端驗證檔裡繞開產品 DI 的做法：手組最小可用的 Dio，請求與解析仍走產品的 API client 與模型（型別化解析層共用、不手寫 JSON）。完整機制與程式碼：TestWidgetsFlutterBinding 會擋掉真實網路。

輸出雜訊治理：預期環境狀態的正確處理路徑

harness 立起後，測試輸出可能固定印出幾行「錯誤長相」的文字——相機偵測的 MissingPluginException、toast 套件的 assert fallback。這些在生產環境是正確的防護路徑，在測試環境是必然觸發的假警報。假警報訓練人忽略輸出，新的真警報混在裡面就被同一個心理過濾器吃掉。

治理原則：測試環境 100% 必然成立的觸發條件，用前置判斷或 harness mock 讓它走正常路徑，讓例外接管只剩真正的例外。

前置判斷放在 runZonedGuarded 的 zone 內而非外——極端環境（binding 未初始化）連 WidgetsBinding.instance 都會拋，放 zone 內讓它落入兜底。分工因此變乾淨：前置判斷處理已知的環境狀態，zone 兜底處理未知的失敗。完整案例與判準：測試輸出的雜訊治理。

假後端的回應序列化：物件 → toJson，不是手寫 JSON

有狀態假後端的回應資料從哪裡來，是 Dart 生態特有的選型：freezed 模型天生雙向（fromJson/toJson），假後端持有模型物件、出口一律 toJson()，服務層走的反序列化路徑與生產環境完全相同。

手寫 JSON 樣板跳過這個閉環的前半段——樣板對不對靠人眼比對 API 文件。實際案例：同一批測試裡的 raw 寫法重踩了產品早已內建處理的分頁包裝（信封解析層的知識被重複實作在測試 helper 裡），改走產品的 API client 與模型後，helper 連同它代表的重複知識一起刪除。

判準一句話：回應形狀的知識只該存在一份。測試裡出現 data['data'] 之類手挖回應欄位的 helper，就是重複知識的訊號。

假後端的狀態演變用 copyWith 在 handler 裡宣告式完成，一個 handler 對應一條已證實的後端行為。toJson 閉環的忠實性由配對的真實後端驗證測試把關——模型的 fromJson/toJson 若與真實後端不對稱，會在那裡先於產品爆出來。完整做法與對照組事故：有狀態假後端用真實模型序列化回應。

建置順序

四個限制的處理有先後依賴：

1. spike：一條最小測試驗證控制器能否在 headless 環境建構並呼叫編排入口
2. harness 收斂：spike 過了之後，把 channel mock + no-op 子類 + postFrameCallback 補位收進共用 bootstrap
3. 檔案隔離規劃：真實後端驗證測試另開檔案、不 import harness、不初始化 binding
4. 雜訊治理：harness 的 channel mock 順便解決大部分雜訊；剩餘的 headless 環境假警報加前置判斷
5. 假後端序列化：以 freezed 模型持有狀態、toJson 出口，seed builder 集中維護初始狀態
6. 第一條劇本：走完一段跨服務業務旅程，斷言散佈在各階段的可觀察結果上

步驟 1 決定後續全部形態——立不起來就回到策略層重新評估（語意級假後端與流程測試的「可測性閘門」段）。

下一步路由

• 策略層的完整判準（什麼時候值得建假後端）→ 語意級假後端與流程測試
• 配對的真實後端驗證（假後端行為漂移的防線）→ 真實後端驗證測試
• 憑證的存放與 CI 注入 → 測試憑證管理
• 各限制的完整 case：headless 控制器、binding 互斥、雜訊治理、假後端序列化

概念位置

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

可觀察訊號與例子

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

設計責任

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

觀察

前端的本地追蹤記錄裡凍結了兩個後端 id：事件發生當下所屬單據的 id、與明細列的 id。這是一個前後端分離的 APP 專案，前端為後端推送的每個事件建立這樣一筆記錄，後續的「取消」「追加」操作用這兩個凍結 id 回寫後端。

後端有一個「合併兩張單據」的操作。實際行為是：建立一張新單據、明細列全部重建（全新 id）、刪除舊單據。合併後，本地記錄裡凍結的舊 id 全部指向已刪除的資料——取消操作永遠失敗、追加操作無聲失效。

判讀

1. 凍結 id 的生死由後端決定，stub 卻由前端決定。單元測試建立記錄時，順手把對應的單據與明細餵進 stub——凍結 id 與 stub 資料出自同一隻手、恆常一致。真實世界裡讓 id 死亡的是後端的重建行為，stub 沒有這個行為，於是「id 失效」這個狀態在測試裡不可能出現。

2. 修復方向也受同一個盲區支配。第一版修復只搬了單據層的 id（合併後通知本地記錄改掛新單據），沒人想到明細層的 id 也死了——因為測試裡明細 id 從未死過。盲區不只遮蔽 bug，還遮蔽修復的完整性。

3. 判斷關鍵：哪個 id 跨越操作仍不變。事後分析發現後端合併時保留了事件記錄的 id（只改外鍵）。「什麼會變、什麼不變」是後端行為的事實問題，推理與記憶都不算出處——合法的出處是可驗的契約文件、或一次實測取證，然後把證實的行為固化進測試環境。

策略

1. 對「參照外部資料 id」的功能，測試必須包含「id 失效」的劇本。凡是前端持有後端 id 的地方，就要問：後端的哪些操作會讓這個 id 死亡？該劇本進測試。
2. 用有狀態的假後端取代由測試餵資料的 stub：假後端自己模擬「合併＝重建明細＋換 id」的行為，前端的活解析邏輯就會在測試裡被真正逼出來。做法見語意級假後端。
3. 實測後端行為一次、固化為測試資產。「合併後哪些 id 存活」這類問題用一次埋 log 實測定案，結論寫進假後端，之後不再依賴任何人的記憶。

下一步路由

• 想建立有狀態假後端 → 語意級假後端與流程測試
• 假後端的行為假設怎麼對真實後端驗證 → 真實後端驗證測試
• 換了測試形態後首跑就抓到問題的實例 → T.C6 流程測試首跑抓到順序 bug

觀察

這個系統的前端以輪詢讀取後端的事件流，把新事件轉成列印輸出；後端的「合併兩張單據」操作會重建明細、更換全部明細 id。T.C5 的修復針對後者：合併後前端要「立即刷新一次快照」，讓後續操作拿到重建後的新明細 id。修復者把刷新放在「同步單據列表」之前。

這個順序踩中輪詢的兩道機制。第一道是過濾：多店環境下，後端事件流混有其他店的資料，前端以本地單據列表為準濾掉非本店的部分。合併後的瞬間，本地列表還停在舊單據——新單據的資料被整批濾掉，刷新等於白做。第二道是差異比對：輪詢以上一輪結果為基準，只把新增的部分觸發輸出；空結果覆寫了這個基準，下一輪輪詢會把整張單據誤判為新增而重複觸發列印。

判讀

1. 「直接塞狀態」是單元測試的合理手段，也是它的邊界。單元測試驗證「取消邏輯在快照正確時是否正確」，把快照塞進去是聚焦的做法。但「快照如何變成正確的」——輪詢、過濾、差異比對這條鏈——不在它的視野裡。順序 bug 剛好住在這條鏈上。

2. 修復引入的 bug 比原始 bug 更難察覺。原始 bug 有使用者回報的症狀；修復引入的順序錯誤沒有立即症狀（要等到下一輪輪詢才重複列印），若沒有流程測試，它會以「偶發重複列印」的形態在生產環境出現，極難回溯。

3. 首跑就紅是價值不是意外。流程測試的建置成本花在假後端與服務鏈的組裝上；一旦組起來，它驗證的是「多個服務對同一份資料的接力是否正確」。單元測試在結構上放掉的正是這段接力。

策略

1. 狀態的「來路」也要被測到。若被測邏輯依賴某份狀態，至少要有一條測試讓狀態走真實的產生路徑（輪詢、過濾、同步），而不是全部直接塞。
2. 編排順序是一種契約。「A 必須先於 B」的約束要同時存在於兩處：編排程式碼的註解（說明不可對調的原因）與流程測試的劇本（順序錯了就紅）。
3. 修復也要過流程測試。針對跨服務互動的修復，合入前先在流程測試上跑一輪——修復引入的迴歸與原始 bug 同樣真實。

下一步路由

• 流程測試的地基怎麼搭 → 語意級假後端與流程測試
• 被繞過的鏈路屬於哪一層職責 → 三層定義與職責表
• 前一集：bug 為什麼漏掉 → T.C5 凍結參照失效被 stub 遮蔽

語意級假後端是針對這個限制的測試形態：一個持有狀態、模擬已證實後端行為的假件，讓多個前端服務對它走完整的互動鏈。業界 test double 分類裡，這對應 Fowler 定義的 fake——有狀態、可運作的簡化實作；「語意級」強調的是行為出處紀律。

與 stub 的差異

兩者的分界在狀態的歸屬：stub 的回應由測試作者逐條寫死，語意級假後端自己持有狀態、讓每個操作演變它。

「模擬後端動詞的效果」是關鍵：對「合併兩筆資料」這類操作，假後端在自己的狀態裡執行完整效果——子項全部重建、舊參照全部失效——與實測證實的真實後端一致。前端若依賴舊參照仍然有效，測試立刻紅。完整情節見 T.C5。至於值不值得為此建一個假後端，判準見文末「結構界限與適用判準」段。

本模組的遮蔽機制章批評「讓 mock 更逼真」是結構性錯誤——mock 終究是開發者理解的副本。語意級假後端與那條批評的差別在三點：模擬止於應用層行為，協議層仍歸 protocol integration test；每條行為有實測出處，而非理解的副本；配對的真實後端驗證測試承擔行為漂移。三點缺一，它就退化成該章批評的對象。

掛載形態：接縫選在哪一層

假後端與前端服務鏈的接縫由既有架構決定，判準是「服務怎麼碰到後端」：

• 多個服務共用同一個 API client 介面（請求都經過同一個抽象出口）→ 注入 in-process 假實作：實作同一個介面、在測試進程內持有狀態。成本最低、執行最快、離線可跑
• 服務各自組請求、直接發 HTTP（缺少共用抽象）→ 本地起一個假 server，把服務的目標位址指過去。多維護一層 server 的啟停與序列化，換到的是連傳輸層一起走過
• 兩種形態混雜（部分服務走 client、部分自己發）→ 先把散落的請求收斂到共用介面，再掛 in-process 假實作；接縫統一之後，假後端才看得到完整的互動鏈

兩種形態各有環境前提：假 server 形態要求服務的目標位址可設定——位址硬編碼時，先把 endpoint 抽成可設定再掛；in-process 注入則要求服務與測試跑在同一個測試進程內。

行為從哪裡來：實測一次、固化為資產

假後端的每一條行為都必須有出處——已證實，而不是「我覺得後端應該是這樣」。否則它只是一個更精緻的假設回放器。

取證方式依成本遞增：

1. 讀後端回應中的診斷資訊（若有 query log 之類的除錯欄位，直接看它做了哪些寫入）
2. 對開發環境的真實後端做一次探測（操作前後直接讀狀態比對）
3. 前端埋 log 實機操作一次

證實後寫進假後端，並遵守配對慣例：假後端每一條行為假設，對應一條真實後端驗證測試（見真實後端驗證測試）。假後端負責讓流程測試快速、確定地跑；驗證測試負責在後端行為漂移時把警報拉響。

可測性閘門：編排住在哪裡

流程測試繞過 UI 皮層、從編排入口以下驅動整條服務鏈——業界詞彙裡接近 subcutaneous test，也常被歸入 integration test 的範疇。它要驅動「真實的編排」，而編排常常住在 UI 層的控制器裡。開工前先做一個 spike：控制器能不能在測試環境裡立起來——具體判定是能在測試環境建構出該控制器並呼叫其編排入口，平台與環境依賴以假件或空實作替換。

spike 走完會分出兩條路。立得起來——平台通道（行動端的原生橋接、web 的 browser API）可以 mock、背景服務可用 no-op 子類替換——測試就直接呼叫編排入口，零漂移。立不起來，剩下兩個選擇：把編排抽到服務層（重構），或在測試裡複製編排步驟並在兩處互相標註（接受漂移風險）。

這個閘門的答案決定整個套件的形態，值得用一條最小測試先驗證，而不是寫到一半才發現。

一併確立驗證邊界：對話框、畫面選取這類純 UI 互動不在流程測試範圍——測試直接呼叫 UI 收集完參數後的編排入口。外接裝置（第二螢幕、印表機）以可注入的假件攔在傳輸出口，斷言送出的資料流與時序（T.C9），列印則以假印表機計數斷言張數。

流程測試的典型劇本

一條劇本 = 一段跨服務的業務旅程，斷言散佈在每個階段的可觀察結果上：

1. 佈置：假後端 seed 初始狀態（資料實體、關聯資源、參照目錄）
2. 前端服務鏈啟動（以輪詢同步架構為例）：同步列表 → 訂閱事件 → 輪詢建立差異比對基準
3. 業務操作：呼叫真實編排入口，執行會改變後端狀態的操作（合併、拆分、刪除這類會重建或釋放資料的動詞）
4. 斷言：假後端的狀態變化（後端該發生的事）、前端的狀態對齊（本地資料該還原或更新）、對外輸出的副作用（外送訊息序列、輸出計數）
5. 追加一輪輪詢：驗證下一個週期把先前的變更辨識為已處理。差異比對基準是輪詢用來判斷「哪些是新資料」的上一輪快照；這一步防的是基準被污染的迴歸形態——空結果覆寫基準，下一輪就把同一筆資料誤判為新增而重複輸出（見 T.C6）

步驟 2 與 5 是輪詢同步架構的情境實例；推播型架構有等價的命題——驗證事件重放時前端只輸出一次、重送的同一事件被辨識為已處理。

隔離紀律是劇本成立的前提：每條流程測試重建假後端實例（或等效重置），劇本之間狀態互不滲漏；seed 用共用 builder 組裝，初始狀態的形狀集中維護，避免每條測試手拼。

價值實例：這個形態的套件在建置過程中，首跑就抓到修復自身引入的順序 bug（T.C6）；一條劇本在「單跑綠、合跑紅」的合跑階段暴露 fire-and-forget（呼叫後不等待）編排的時序競態（T.C8）；雙行為開關（假後端同時模擬後端會做與不會做兩種行為、由開關切換）配合真實後端驗證測試，為一個先前只能互相猜測的前後端責任問題提供歸因定案的手段（T.C7）——開關是歸因期對「已證實」規則的暫時例外（其中一種行為尚未證實），定案後收斂回單一已證實行為。

結構界限與適用判準

這套形態的前提是後端無法在本機或容器裡啟動、只有共用測試環境可用（真實後端驗證測試在同一個前提下運作）。前提不成立時，成熟工具鏈有更直接的選項：

• 後端可容器化啟動 → 直接起真後端（testcontainers 類工具），假設由真實行為檢驗
• provider 團隊可配合 → consumer-driven contract test（如 Pact）讓後端在自己的 CI 裡驗證前端的假設
• 互動是線性單劇本 → 錄放式（record / replay）工具即可覆蓋

三者皆否、且需要有狀態的多劇本接力時，才輪到自建語意級假後端——錄放式的 cassette 是線性回放，做不到狀態接力。

語意級假後端固化的是「已知」。後端若默默改變行為，假後端不會跟著變，流程測試照樣綠——這個洞由配對的真實後端驗證測試補上。兩者合起來才是完整的形態：

• 假後端＋流程測試：快、確定、可在離線與 CI 執行，防「前端改壞已知正確的流程」
• 真實後端驗證測試：慢、需環境，防「後端行為漂移讓已知變成過期」

建置與否用兩個自查問題判斷：專案裡是否有多個前端服務對同一份後端狀態接力？是否已經出現「對後端行為假設錯誤」型的漏網 bug？兩者都是 → 值得建。單一服務的 CRUD 驗證，由測試餵資料的 stub 就足夠，假後端持有狀態的維護成本高於它換到的增量。成本量級拆解：初版包含狀態模型（定義假後端持有的資料實體）、最先固化的 2-3 條已證實行為、加上一條端到端劇本——工作量主要取決於需要模擬的動詞數，2-3 個動詞是天級，超過 10 個動詞時先從最高風險的子集開始、其餘增量補入。這兩個數字是經驗閾值，依動詞的狀態複雜度調整——牽涉關聯資源連動（刪除單據要連帶釋放佔用）的動詞，一個就抵得上數個純 CRUD 動詞。之後隨新證實的行為增量維護。持有成本還包括失敗定位：流程測試紅燈時，除錯半徑橫跨 seed、服務鏈、假後端狀態到斷言的整條鏈，定位成本高於單元測試。維護面的 tripwire：後端行為高頻變動的時期，假後端加驗證測試是雙份維護、成本隨變動頻率放大——變動頻繁到每次迭代都要改兩處時，重新評估這套形態。

建置起步順序

決定建假後端後，按以下順序推進：

1. 可測性閘門 spike：用一條最小測試驗證編排的宿主（控制器或服務入口）能否在測試環境立起來——這一步的答案決定後續全部形態（Dart/Flutter 生態的平台耦合中和手段見流程測試基礎設施）
2. 掛載形態決定：依服務碰後端的方式（共用 client 介面 / 各自發 HTTP）選 in-process 注入或假 server
3. 狀態模型：定義假後端持有的資料實體與初始 seed builder
4. 第一條已證實行為：對真實後端取證（診斷資訊 / 探測 / 埋 log），固化為假後端的第一個 handler
5. 第一條劇本：用 seed + handler 走完一段跨服務業務旅程，斷言每階段的可觀察結果
6. 配對驗證測試：在真實後端驗證測試補一條對應斷言

步驟 4-6 形成增量循環：每證實一條新行為，假後端加一個 handler、流程測試加一條劇本、驗證測試加一條斷言。

下一步路由

• 配對的另一半 → 真實後端驗證測試
• stub 回放假設的完整案例 → T.C5 凍結參照失效被 stub 遮蔽
• 測試該寫成什麼樣子 → 測試註解與命名紀律
• Dart/Flutter 生態的實作限制（headless 立控制器、binding 互斥、假後端序列化）→ 流程測試基礎設施

觀察

前端與後端的契約是：刪除一張單據時，後端一併釋放該單據佔用的資源狀態（例如場地、座位這類由後端控管的佔用旗標）。使用者回報：刪除後，資源在畫面上仍顯示為佔用中。

初步懷疑指向後端違約。但讀前端程式時發現：刪除編排在成功後沒有任何一次資源狀態的刷新——也就是說，即使後端照契約釋放了，畫面也會殘留舊的「佔用中」，症狀與後端沒釋放完全無法區分。

判讀

1. 「畫面顯示的」不等於「後端狀態」。前端畫面是「上次同步的後端狀態」的快取；任何會改變後端狀態的操作，若後續沒有同步，畫面就殘留舊值。這類 bug 的歸因第一步是：繞過畫面，直接讀後端。

2. 兩種行為都寫測試，而不是先賭一邊。假後端的開關讓「後端會釋放」與「不會釋放」兩個世界都存在；前端編排在兩個世界裡的正確行為不同（前者要畫面還原、後者要誠實顯示佔用）。分開鎖定後，無論真實後端是哪種，前端這半的責任都已被測試涵蓋。

3. 真實後端測試把「歸因」變成一次執行。紅＝後端違約（測試本身成為修復的驗收標準）、綠＝前端問題。不需要會議、不需要來回猜測——而且這次的結果與最初的懷疑相反，正說明沒有證據的歸因有多不可靠。

4. 延遲重讀是必要的容錯。後端可能非同步釋放（即刻讀還是佔用、幾秒後才釋放）；驗證測試即刻與延遲各讀一次，把「同步釋放／非同步釋放／未釋放」三種結果區分開，各自對應不同的前端處置。

策略

1. 歸因順序：直接讀後端狀態 → 確認後端行為 → 再回頭檢查前端的同步時機。跳過第一步的歸因都是猜測。
2. 「改變後端狀態的操作」在前端編排的收尾必須有對應的同步。這條規則可以巡檢：列出所有會改變資源狀態的操作，逐一檢查操作後有沒有刷新。
3. 定案後收斂測試：真實行為確定後，把假後端的開關定死、移除錯誤行為那條測試分支——錯誤行為分支違反假後端「只固化已證實行為」的定位，後端未來變壞由配對的真實後端驗證測試接手。雙行為測試是歸因期的工具，不是永久資產。

下一步路由

• 真實後端驗證測試的工程化 → 真實後端驗證測試
• 假後端的行為從哪裡來 → 語意級假後端與流程測試
• 同場景的另一種畫面殘留 → T.C6 流程測試首跑抓到順序 bug

概念位置

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 失效」的劇本納入測試範圍——見凍結參照與活解析。

核心議題：假後端的回應資料從哪來？手寫 JSON 字串、還是建構真實模型物件再 toJson()？POS App 的流程測試選了後者，理由不是美觀——是「後端回應形狀的知識」在專案裡應該只有一份（產品的模型解析層），fixture 自己再寫一份就會分岔。 案例骨幹：有狀態假後端以 freezed 模型（單據、明細、記錄）持有狀態、handler 用 copyWith 演變狀態、出口一律 toJson()。同一時期另一批用 raw JSON 手刻請求的測試，重踩了「列表回應帶分頁包裝」的問題——產品的回應信封解析早就內建了這層 unwrap，手刻等於把已解決的問題再解一次。

1. 假後端的回應出口：物件 → toJson，不是字串樣板

有狀態假後端攔在 HTTP adapter 層，對每個端點回放狀態。回應的組裝方式：

1// 狀態就是真實模型物件
2List<Cart> carts;
3List<Record> records;
4
5// 出口統一序列化——服務層拿到的 JSON 與真實後端同構
6if (isCartList(request)) {
7  return envelope([for (final c in carts) c.toJson()]);
8}

freezed 模型天生雙向（fromJson/toJson），這保證了一個閉環：假後端 seed 的物件 → toJson → 服務層 fromJson → 前端邏輯，服務層走的解析路徑與生產環境完全相同。手寫 JSON 樣板跳過的正是這個閉環的前半段——樣板對不對，靠人眼比對 API 文件。

2. 對照組事故：raw 手刻重踩分頁包裝

同一時期，另一批對真實後端發請求的測試最初用 raw JSON 手刻（自組請求、手挖回應欄位）。首跑失敗：

1type '_Map<String, dynamic>' is not a subtype of type 'List<dynamic>'

真實後端的列表端點帶分頁包裝——data 不是陣列，是 { data: [...], previousPage, nextPage, ... }。而產品的回應信封模型早就內建了「嘗試解分頁包裝」的邏輯，生產 App 天天在正確處理這個形狀。raw 寫法等於把一個已解決的問題重新發現、重新修補（在測試裡加了一個 _listData helper）——直到改用產品的 API client 與模型解析，這個 helper 連同它代表的重複知識一起刪除。

教訓一句話：回應形狀的知識只該存在一份。fixture 或測試裡出現第二份（手寫 JSON、手挖欄位），它與第一份的分岔只是時間問題。

3. 狀態演變用 copyWith，行為住在 handler

有狀態假後端與「回放固定回應的 stub」的分水嶺在於它模擬後端動詞的效果。freezed 的 copyWith 讓這件事保持宣告式：

1// 「合併」的效果：明細全部換新 id、記錄改掛新單據
2final newDetails = [for (final d in old.details) d.copyWith(id: newId())];
3records = [for (final r in records) r.copyWith(parentId: mergedId)];

每個 handler 頭上一句話描述它模擬的後端行為（來源是實測證實，不是猜測）；測試 seed 初始物件、跑真實服務鏈、斷言假後端的狀態變化與前端的對齊結果。方法論層的完整討論見語意級假後端與流程測試。

4. 邊界：toJson 回放的前提是模型忠實

這個做法有一個隱含前提：產品模型的 fromJson/toJson 對真實後端是忠實的。若模型本身漏了欄位、轉換器不對稱，假後端的閉環會把錯誤一起閉進去——測試綠、對真實後端壞。補這個洞的是配對的真實後端驗證測試：它走同一套模型打真實環境，模型與後端的形狀分岔會在那裡現形（分頁包裝那次事故正是被它抓到的）。

5. 可複用的判準

1. 假後端／fixture 的回應一律「建構模型物件 → toJson」，不手寫 JSON 字串。
2. 測試裡出現「手挖回應欄位」的 helper（data['data'] 之類）＝重複知識的訊號，改走產品解析層。
3. 有狀態假後端的狀態演變用 copyWith 在 handler 裡宣告式完成，一個 handler 對應一條已證實的後端行為。
4. toJson 回放閉環的忠實性由真實後端驗證測試把關——兩者是配對關係，不是二選一。

下一步

• 方法論層 → 語意級假後端與流程測試
• 配對的驗證層 → 真實後端驗證測試
• freezed 模型設計的機制層 → Freezed 三層結構解剖