Stub-to-Production Gap Risk¶
概念概覽
Stub 的雙面性¶
核心知識¶
Stub 的雙面性¶
Stub 在開發初期是必要的佔位，但若長期未被替換，會造成測試通過但 production 路徑空殼的假象。
兩個具體案例¶
ResolveContentClosure stub：
// sticker_season_handler.go:88
func (h *StickerSeasonHandler) ResolveContentClosure() {
return nil, nil // stub，尚未實作
}
activity_admission.go:67（准入邏輯）
- activity_config_sync.go:274（config drift detection）
- activity_settlement_service.go:390（settlement frozen-config）
ScheduleConfigLoader 缺失：
- activity_config_sync.go:48 有 setter，但 production 的 LoadScheduleEntries 實作在 repo 中找不到
- 只有 test mock 存在，activity_twirp.go:488 若 loader 未設定會直接報錯
識別方式¶
- grep repo 中實際有 production 實作 vs 只有 test mock
- 追蹤 stub 被哪些核心路徑依賴（影響範圍評估）
- 判斷「帶著 stub 進入 phase 後，接線驗證是否有意義」
經驗教訓¶
-
stub 讓測試通過是假的安全感，必須在進入接線 phase 前確認核心路徑的 stub 是否已替換
-
ScheduleConfigLoader 這類只有 mock 無 production 實作的情況，會讓整個 config sync 功能在 production 完全失效
-
ResolveContentClosure 影響三個不同 service 的核心路徑，stub 的影響範圍遠超表面
常見陷阱¶
-
只看 unit test pass/fail，未確認 production code path 是否有 stub 佔位
-
把『有 test mock』誤認為『有 production 實作』，需要明確區分兩者
相關概念¶
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Activity Framework Settlement Idempotency — 共享：
activity-framework/ 獨特：idempotency,settlement - JIT Blind-spot Testing — 共享：
testing/ 獨特：integration-test,microservices
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-04-02 | 431f3410-f7d5-461d-8a0b-e1ea3f999e73 | 記錄 stub 實作通過 test 但阻斷 production 路徑的具體風險模式，以及 ScheduleConfigLoader / ResolveContentClosure 兩個案例 |