JIT Blind-spot Testing¶
概念概覽
方法論路徑¶
核心知識¶
方法論路徑¶
JIT 盲點測試按以下順序執行：
每個 gate 的目的不同： - startup path：驗證初始化依賴（如 ConfigManager）失敗時的行為 - write path：追蹤 adapter → repository 呼叫鏈，確認參數符號、守衛邏輯一致 - concurrency：確認 lock 失敗路徑的 metric 記錄不會造成誤報 - anti-bias gate：強制審查「成功路徑 mock 掩蓋了真實失敗」的場景 - realism gate：確認 fallback（如 DB fallback）重建的狀態是否完整
為何 unit test 無法替代¶
Mock 會繞過 adapter 層，導致以下類型的 bug 在 1000+ 測試中完全不可見：
- DeductCurrency 傳負數給有正數守衛的 repository 方法
- ResumeBattle DB fallback 不重建 ItemUsages/Purchases
- ConfigManager fail-open 在 fail-closed 依賴場景下造成 runtime crash
關鍵結論¶
每個新模組的 adapter 接線至少需要一個**真實路徑 integration test**（非 mock），這是抓 adapter 接線 bug 的最低保障。
經驗教訓¶
-
Adapter 接線錯誤是最難被純 mock 單元測試抓到的 bug 類別，必須靠逐行追蹤 adapter → repository 呼叫鏈
-
cleanup goroutine 在 lock 失敗時仍記錄 success 會產生監控誤報，監控誤報比沒監控更危險
-
fail-open 設計需明確區分「哪些下游服務有 fail-closed 依賴」，否則降級會引發 runtime error
常見陷阱¶
-
純 mock unit test 驗證通過不代表 adapter 接線正確
-
负数/正数守衛在 adapter 層與 repository 層分開定義時容易不一致
-
DB fallback 恢復基本狀態但遺漏衍生狀態（如 item usage log），導致崩潰後對帳邏輯錯誤
最佳實踐¶
-
每個 adapter 模組至少寫一個 integration test，覆蓋真實路徑
-
production 環境 ConfigManager 初始化失敗應 fatal，fail-open 僅適用本地開發
-
metric 只在操作真正成功時才更新 success counter
相關概念¶
- adapter-pattern-go----dangling-------dangling---
- ConfigManager Fail-open Anti-pattern
- Go Microservice Production Readiness Scoring
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Release Gate Layering — 共享：
production-readiness/ 獨特：go-live,p0 - Stub-to-Production Gap Risk — 共享：
testing/ 獨特：activity-framework,production
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-17 | 056f9176-f6b2-4663-9b7e-19679837f204 | 定義了一套針對 Go 微服務的盲點測試方法論，能抓到 1000+ 個 unit test 都未能發現的 P0 adapter 接線錯誤 |