"Strategy"
- 三層定義與職責表
Unit Test / Protocol Integration Test / Screen State Test 各層職責、驗證目標與盲區的完整論述
- 判斷原則:什麼時候需要 protocol integration test
從服務架構特徵判斷是否需要 protocol integration test 的決策流程 — 協議複雜度、mock 寬鬆度、失敗靜默度三個維度
- 反模式:用 mock 數量彌補 mock 盲區
為什麼增加 mock test 數量無法跨越 mock 的結構性盲區 — 從 192 個 test 全過的案例拆解數量與覆蓋率的真正關係
- 主策略 + 補強策略:選擇不必互斥
多策略並非「五選一」、可分層疊加:root-cause fix(解結構問題) + UX 補強(解使用者感知)通常雙打比單選更穩。判準三條:解不同層 / 沒副作用衝突 / 增量成本可接受。把「策略選擇」預設成單選、會放掉互補可能、產生「結構修了但使用者體驗仍差」或「UX 蓋過去但結構還壞」。
- Capability gap 的對策三層階梯:expectation → augment → rebuild
系統有 capability gap(功能不滿足使用者預期)時、對策有三層階梯:L1 expectation alignment(UX hint、訊息精準)、L2 augmenting computation(補一層計算 close gap)、L3 structural rebuild(換 index / engine / 演算法)。三層成本、覆蓋率、脆弱度遞增、不必每次跳到 L3。本卡是 #75 主+補強策略的「不疊加、選層級」變種、跟 #59 五策略矩陣可疊加使用。
- L1 + L2 疊加時的訊號一致性:UX hint 跟自動 fallback 講的話要對齊
把 expectation alignment(L1)跟 augmenting computation(L2)疊加時、兩個 layer 給使用者的訊號可能矛盾:L1 說「請改打字」、L2 卻自動找到了;L1 說「資料可能延遲」、L2 卻 stale-while-revalidate 自動 refresh。沒對齊時使用者困惑。本卡定設計 protocol:兩個 layer 講同一個 capability gap、訊號要 layered consistent、不是 redundant 也不是 conflicting。本卡是 #75 + #86 + #79 在「使用者訊號層」的整合。