前言：沒有覆蓋率門檻，缺口靠什麼被補上？

前面幾天看到的「順路補測試」，是在一個完全沒有覆蓋率門檻的套件裡發生的——phpunit.xml 雖然設定了覆蓋率報表輸出，但 CI 用 --no-coverage 把它關掉了（這是第一部 Day 07 提過的事實）。今天把這件事跟前面的觀察接起來：沒有制度在推動的時候，測試缺口到底靠什麼被補上？

今日目標

• 把 Day 07（覆蓋率設定被關掉）跟 Day 09-10（順路補測試/沒被順路照顧到的對照組）兩條線接起來
• 理解「靠自覺」跟「靠制度」是兩種完全不同的驅動力，各自的可靠度不一樣
• 分辨這個套件目前實際運作的驅動力是哪一種
• 想清楚：如果想把「靠自覺」換成「靠制度」，第一步要做什麼（留給第四部實際動手處理）

目前這個套件的驅動力：完全靠自覺跟機會

把前幾天的觀察排在一起看：

• 沒有覆蓋率門檻擋著（CI 用 --no-coverage）——沒有工具會在某段程式碼覆蓋率過低時擋下 PR 或發出警告
• 測試補齊靠的是「順路」——開發者因為別的理由打開某個檔案，才會回頭注意到旁邊的缺口
• 安全關鍵路徑（CheckMacValue 驗證）測得特別紮實——靠的是開發者對「這裡出錯後果很嚴重」的直覺判斷

三件事合起來，可以歸納成同一句話：這個套件的測試覆蓋,目前完全靠開發者當下的自覺跟隨機出現的修改機會在推動,沒有任何制度性的機制在背後兜底。

靠自覺 vs 靠制度，差在哪

靠自覺的好處是輕量、不需要額外的工具或流程，開發者對風險的直覺判斷（例如「簽章驗證失敗一定要測」）往往比死板的覆蓋率數字更精準——覆蓋率工具不會告訴你「這行程式碼比那行程式碼更需要測試」，但一個資深工程師的直覺會。

靠自覺的壞處也很明顯：它完全不保證均勻。Day 10 已經證明過，RefundRequest、VoidRequest 因為介面穩定、很少被重新打開,就一直沒等到補測試的機會——不是沒人意識到這個缺口重要，而是沒有機制強迫任何人在缺口出現的當下就處理它。靠制度（例如覆蓋率門檻、CI 檢查）的好處剛好相反：它不管你當下有沒有動機,只要條件沒達到就會被擋下來，逼著缺口被看見。

❌ vs ✅：等待自覺 vs 設計一個會主動提醒的機制

❌ 完全依賴自覺
"等哪天有人需要改 RefundRequest,
 他應該會順便注意到測試不夠"
→ 如果這個檔案剛好很穩定,永遠不會有這一天

✅ 用制度把「順路」的機會人為製造出來
"設定覆蓋率門檻,每次 CI 跑測試時,
 主動列出覆蓋率低於某個標準的檔案，
 不需要等某個開發者剛好打開那個檔案"
→ 用工具把「順路看到」變成「一定會看到」

**靠自覺的機制能不能運作，取決於運氣好不好；靠制度的機制，運作與否不看運氣。**這不是說靠自覺一無是處——Day 05 提過的安全關鍵路徑測得特別紮實，就是靠自覺做對的案例。但靠自覺沒辦法保證均勻覆蓋每一個角落，這正是靠制度存在的理由：不是取代自覺,而是補上自覺照顧不到的地方。

今日思考題

你的專案裡有沒有覆蓋率門檻？如果有，它擋下過什麼？如果沒有，你覺得目前的測試覆蓋均勻嗎，還是也跟這個套件一樣，靠著某些程式碼「比較常被打開」在決定覆蓋程度？

今日重點回顧

• 這個套件目前的測試覆蓋完全靠開發者的自覺跟隨機出現的修改機會在推動，沒有制度性機制
• 靠自覺的優點是判斷精準（安全關鍵路徑測得特別細），缺點是不保證均勻（穩定的模組容易被冷落）
• 靠制度的優點是不依賴運氣，缺點是需要額外投入建置跟維護成本
• 兩者不是互斥的，靠制度是用來補上靠自覺照顧不到的死角，不是要取代它

明日預告

明天回到 AI 協作的實作面：怎麼具體下 prompt，讓 AI 在幫你補功能的同時，主動幫你檢查同一個檔案裡有沒有其他測試缺口，把 Day 11 講的心態，變成真的能照著做的方法。