這裡回答的是「投資順序」。值不值得在既有程式碼上加測試（相對於重寫）是更上游的判斷，語意級假後端與流程測試的「結構界限與適用判準」段有討論不同規模的取捨。

判斷起步層的自查

測試策略的三層——unit、protocol integration、screen state——每層的投資回報取決於風險集中在哪裡。照測試金字塔從 unit 開始往上疊是一種預設路徑，但 legacy 專案的風險分布很少均勻：某些系統的風險集中在內部邏輯、某些集中在外部互動、某些集中在流程編排。起步層對準風險集中處，每條測試的邊際收益最高。

三個自查問句幫助定位風險集中處：

過去半年的 bug 報告集中在「算錯」還是「連錯」？

• 算錯（金額計算、狀態轉換、資料轉換的錯誤）→ 風險在內部邏輯，unit test 的攔截面最大
• 連錯（API 回應格式改了沒跟上、認證握手失敗、訊息格式不相容）→ 風險在外部互動，protocol integration test 的攔截面最大

系統的正確性有多大程度取決於「我們對外部服務行為的假設」？

• 系統主要依賴自己的計算和規則 → unit test 先行
• 系統的核心價值在「跟第三方服務的互動」（支付閘道、物流 API、認證服務）→ protocol integration test 先行，確保互動契約正確

Bug 是在哪個層面被使用者發現的？

• 使用者回報的是「按了按鈕沒反應」「畫面顯示的跟預期不同」→ 風險在 UI 行為與導航，screen state 驗證先行
• 使用者回報的是「資料不對」「扣款金額錯」→ 風險在底層邏輯，往 unit 或 protocol integration 定位

三個問句不互斥——一個系統可能同時在內部邏輯和外部互動都有高風險。此時選風險造成的業務損害更大的那一端先投資。

第三條問句指向的 screen state test 先行路徑沒有列在下面的三條路徑裡，因為它的建置前提與前三條不同——需要 UI 測試框架（widget test / Playwright）已能在專案中執行。若風險確實集中在畫面狀態的完整性（狀態轉換遺漏、佔位頁面殘留），以狀態矩陣為 test case 來源是最直接的起步形態。

三種起步路徑

路徑一：Unit test 先行

bug 報告集中在「算錯」（金額、狀態、轉換），而且這些邏輯的輸入輸出邊界可辨識——函式簽名清楚、依賴可注入或可隔離。

起步策略：從失敗代價最高的業務邏輯開始。不是從最容易測的函式開始——最容易測的通常是工具函式（字串處理、日期轉換），它們的失敗代價低。找到「算錯了會直接造成客訴或財損」的邏輯區塊，從那裡寫第一批 unit test。

常見阻力與對策：legacy 程式碼的依賴常常是纏結的（一個計價函式裡面直接呼叫資料庫、呼叫外部 API、讀取全域狀態）。逐步解耦是理想做法，但前幾條測試不需要完美的依賴注入——用 monkey patching、module-level mock、或 subclass override 先把依賴隔開，換到第一批測試能跑。架構層面的重構在有測試保護之後再做，順序反過來（先重構再測試）會讓重構本身失去安全網。

接續路由：unit test 建立起對內部邏輯的攔截後，下一步判斷是否需要 protocol integration test 補上外部互動的盲區。判準：mock 遮蔽機制描述的哪些問題在這個專案可能成立。

路徑二：Protocol integration test 先行

系統的核心價值在整合——聚合多個外部服務的資料、轉發訊息到不同通道、對第三方 API 做操作。內部邏輯相對薄（主要是組請求和轉格式），風險集中在「跟外部服務的契約是否正確」。

起步策略：盤點系統連接的所有外部服務，按兩個維度排序——變動頻率和失敗影響。變動頻率高（API 版本升級快、回應格式常改）且失敗影響大（付款、認證、核心資料同步）的服務，優先寫 protocol integration test。

可行性前提：外部服務需要一個可測試的環境——sandbox、staging、或可在本機啟動的服務實例。如果外部服務沒有測試環境（某些第三方 API 只提供生產環境），protocol integration test 的成本會大幅上升；這時候先用 HTTP contract test 對著 API 文件寫 schema 驗證，以契約測試替代。

接續路由：protocol integration test 確認外部契約後，回頭用 unit test 補內部邏輯的覆蓋。測試策略的三層定義描述了每層的職責與盲區。

路徑三：流程測試先行

出錯頻率最高的功能橫跨多個服務的接力——前端收到使用者輸入後，經過驗證、計算、外部呼叫、狀態更新、通知，最終結果正確要求整條鏈都正確。單獨測任何一層，攔截率都偏低。

起步策略：找到一條「出錯頻率最高」或「出錯後果最嚴重」的業務流程，把它寫成一個端到端的流程測試——從編排入口驅動整條服務鏈。如果被測編排可以從 UI 層抽離（語意級假後端與流程測試的「可測性閘門」段描述了判定方法），走 subcutaneous test 形態；抽不出來就走 E2E。

代價意識：流程測試的建置和維護成本高於 unit test 和 protocol integration test。Legacy 專案的編排通常跟 UI 框架、全域狀態、平台依賴交織在一起，拆開接縫的前置工程量大。撤退訊號用結構性阻力判斷而非時間倍數：拆接縫時發現需要改動的生產模組超過三個、或第一條 spike 需要的假件數超過五個，代表耦合度超出流程測試先行的成本預期——回到路徑一或路徑二先建低成本的攔截，有部分覆蓋比沒有覆蓋好。這兩個數字是經驗閾值：改動三個以上模組代表波及面超出單一功能的接縫、spike 工期從天級跳到週級；假件數超過五個代表測試的假設比被測邏輯還多。團隊可依自身的模組粒度調整。

接續路由：流程測試建立後，用 unit test 覆蓋流程中各段服務的內部邏輯——流程測試紅燈時，有 unit test 才能快速定位是哪一段出問題。這條接續不是可選的收尾：流程測試先行換到的是攔截率，代價是除錯半徑橫跨整條服務鏈、定位成本高於單元測試。細粒度回饋被延後、不是被放棄，延後期間的定位成本就是這條路徑的已知帳單。定位成本的討論見語意級假後端與流程測試的「結構界限與適用判準」段。

遷移安全網：先有 characterization test 再改

三種路徑都涉及一個共同的操作風險：在沒有測試保護的程式碼上做改動（加測試本身常常需要調整程式碼結構——提取函式、注入依賴、暴露接縫）。Characterization test 是這個操作的安全網。

Characterization test 鎖住的是「現在的行為」，不關心行為是否正確。寫法是對著現有程式碼跑一次、把輸出記錄下來當預期值。改動後全綠代表「行為沒變」，紅燈代表「行為改了」——紅燈不一定是 bug，但它告訴你改動的影響範圍。

這個工具在 legacy 專案起步階段的價值在於降低重構風險：要把纏結的依賴拆開才能寫 unit test，但拆的過程可能改壞現有行為——characterization test 先鎖住行為，讓拆解有安全網。拆完、unit test 寫好後，characterization test 的歷史使命完成，可以視重疊程度逐步移除。兩者的職責分界：characterization test 斷言「行為不變」，unit test 斷言「行為正確」——混在一起會讓紅燈無法歸因是「行為改了」還是「行為本來就錯」。實作經驗與平台依賴的處理見 characterization test 當遷移安全網。

下一步路由

• 測試三層各自的職責與盲區 → 測試策略三層定義
• Mock 遮蔽機制（為什麼 unit test 有結構性盲區）→ Mock 遮蔽機制
• 語意級假後端的適用判準 → 語意級假後端與流程測試
• Characterization test 實作經驗 → characterization test 當遷移安全網
• Protocol integration test 的定義與邊界 → Protocol integration test 定義
• 起步層選定後、單條測試該測什麼（未來哪種改壞要被擋）→ 測試的價值發生在它變紅的那一刻

概念位置

當依賴纏結到必須先拆解才能寫正確性測試、而拆解本身就可能改壞行為時，characterization test 補上這段真空期的回饋——這是它唯一的存在理由。依賴纏結的典型樣貌是mock 遮蔽描述的那種處境：程式碼直接呼叫外部服務、沒有可注入的介面。這個處境在 legacy 專案的起步順序的「遷移安全網」段有完整的操作判準——包含三種起步路徑各自何時需要它。

可觀察訊號與例子

改動範圍不可知時——沒有測試、依賴纏結、沒人記得它該回傳什麼——先鎖行為再動手；範圍可知時（規格明確、依賴已可注入）直接寫正確性測試更划算。判斷落點就在這條分岔上：它的價值來自不確定性，不確定性消失，它就失去存在理由。

設計責任

這類測試自帶退場條件，維護者要負責執行它：正確性測試覆蓋同一段行為後，characterization test 的使命結束、應該移除。留著不移除的代價是雙份維護，且兩份測試對同一行為的斷言可能分岔。與 mock 遮蔽的關係值得留意——characterization test 記錄的是含既有 bug 的行為，它保證的是「沒改壞」，不保證「是對的」。

這也讓它成為判準由實作推導這件事在站內唯一的合法形態：預期值刻意取自被測程式的實際輸出，是設計選擇而不是失誤。代價要算清楚——它因此抓不到需求被誤讀那一類，保留下來的驗證力限於崩潰、回歸與內部不一致。把它當成正確性測試用，就是把一個刻意的取捨誤當成保證。

觸發場景：POS 專案要做金額型別的全面遷移（Decimal 換 Money extension type），動的是全部 model 的金額欄位。測試目錄裡出現一批名字帶 _characterization_test 的檔案、開頭都有同一段宣告：「在 Money value object 遷移前建立、鎖住現有行為」 疑問來源：這批測試跟一般的單元測試差在哪？為什麼連「找零算出負數歸零」這種邊界怪癖也被鎖進去？ 整理目的：記下 characterization test 的方法、跟正確性測試的分工、以及它依賴的測試環境前置（原生依賴的三個斷點） 本文邊界：素材是該專案的五個 characterization 測試檔與 DEVLOG 的測試環境除錯史；characterization test 是 Michael Feathers 在 legacy code 領域的術語、這裡是它在型別遷移的應用

斷言的對象是「現況」、包括現況的怪癖

characterization test 跟一般測試共用全部語法、差別只在斷言的依據：一般測試斷言規格（找零應該是多少）、characterization test 斷言現況（現在的實作算出多少）。寫法是對著舊實作跑一次、把輸出原樣釘進 expect——實作是測試的 oracle、不是規格。

所以連怪癖也照鎖：現有實作在找零算出負數時歸零、這個行為對不對是另一回事，characterization test 把它鎖住。五個檔案的分佈跟著遷移的影響面走——checkout 的應付金額 fold 與現金找零、order 的小計、cart item 的價格計算、product spec 的三種價格——遷移會經過的每條金額計算路徑、各有一張行為快照。

分工的必要性在遷移期間顯形：換型別的過程中紅燈亮起，唯一要回答的問題是「換壞了、還是本來就錯」。characterization test 的紅燈只有一種含義（行為變了、遷移引入了差異）；如果這批測試混著「找零不該是負數」的正確性期望，紅燈就要逐個歸因——遷移的每一步都拖著這個排查成本。正確性的討論值得做、但排在遷移完成之後、在綠的基線上做：那時改行為的 diff 乾乾淨淨只有行為修正、不會跟型別替換攪在一起。

這跟測試分診的洞見同源：測試訊號的價值取決於它的含義夠不夠單一。characterization test 是刻意把含義收窄到「變 / 沒變」一個 bit 的設計。

退場：遷移完成後、快照可以轉正

characterization test 的生命週期跟著遷移走。遷移全綠收工後有兩條路：把有規格依據的斷言轉正成行為測試（找零的正常路徑）、把當初鎖住的怪癖開案處理（負數歸零是不是該改成拋錯？——現在可以安全地討論了，因為改它的 diff 不會跟遷移混在一起）。留著不動也無害、它繼續當回歸網——但檔名裡的 characterization 字樣要保留，它告訴未來的讀者「這些斷言記錄的是某個時刻的現況、不是設計承諾」。

前置：測試環境的原生依賴三個斷點

這批測試能跑的前提、在同專案 DEVLOG 的除錯史裡有完整的代價記錄——flutter test 的環境沒有原生 plugin 與 FFI，三個斷點三種症狀：

三個事件的解法收斂成同一個模式：原生依賴在測試環境一律要有替身、用 Get.put<T>(testInstance) 綁進依賴注入。症狀查表的價值在診斷速度——dlsym 字樣指向 FFI、LateInitializationError 指向沒被初始化的服務欄位、plugin 名字出現在錯誤裡就是 plugin 斷點；三種在第一次遇到時都像靈異事件、記下來之後都是五分鐘的事。Rive 那條的細節值得注意：mock 頁面保持了相同的 UI 結構與 Key，測試驗證邏輯不用改——替身的職責是補環境、不是簡化被測物。

判讀徵兆

• 即將進行「換底不換行為」的遷移（型別、ORM、序列化庫）而現有測試稀疏——先補 characterization、對著舊實作寫、怪癖照鎖
• 遷移期間紅燈需要逐個討論「這是不是本來就錯」——正確性期望混進了安全網，拆開
• characterization 檔案在遷移完成很久後仍在、且被當成規格引用——轉正或標註，快照不是承諾
• 測試錯誤含 dlsym / plugin 名 / LateInitializationError——原生依賴斷點，查替身清單、缺的補上

相關閱讀

• 這張安全網守護的遷移：Money 三段遷移——characterization test 在那篇的角色是配角、本文是它的完整方法
• 訊號含義要單一的同源原則：16 個失敗只有 2 個是缺口、紅燈在量什麼
• 替身的反面教材：1101 行自建測試基礎設施——替身補環境是正當的、替身變平行框架就過了界