測試應該寫幾多？用風險決定，唔好只追覆蓋率

覆蓋率答唔到所有問題

覆蓋率可以話畀你知測試執行過邊啲程式碼，幫你發現遺漏。但某行執行過，唔代表有人驗證咗佢嘅結果；分支全部行過，亦唔代表所有輸入組合都正確。

所以唔應該將專案硬分成「核心 100%、常用 80%、少用 0%」。先睇錯咗有幾大影響，再決定要用咩證據證明佢正常。

1. 先搵出失敗代價

呢張表係問題清單，唔係按資料夾名稱自動分類。admin/ 入面可以有高風險操作，utils/ 入面可以藏住付款計算。

2. 叫 Claude 先讀資料流，唔好先報百分比

讀取我指定嘅模組、呼叫位置同現有測試，只做盤點。

每個重要行為列出：

- 使用者或系統依賴咩結果；
- 出錯會影響咩資料或操作；
- 現有測試驗證咗咩，未涵蓋咩；
- 最值得補嘅具體案例同理由。

唔好用檔案名稱代替閱讀，唔好憑空估覆蓋率。冇讀到、未執行同未知嘅部分分開列明。

先由近期改動、曾經出錯或者影響大嘅路徑開始。範圍太大就分批，保留已讀檔案清單，唔好一次叫模型「全面審閱」就當完成。

3. 補測試時，先補會捉到錯嘅案例

假設匯入器遇到重複 ID：你要先定義係拒絕整批、略過重複，定係更新原有資料。未定規則之前，多寫幾個測試只會將猜測固定落嚟。

規則定好之後，測試應該檢查輸出、持久化結果同失敗處理。例如「回傳成功」之外，核對冇重複建立資料；部分失敗之後重跑，核對結果仍然一致。唔好只斷言某個 mock 函數有被呼叫。

對一個已知錯誤，先寫會重現佢嘅測試，確認修正前失敗、修正後通過。對外部合約，安排受控整合測試；對人手操作流程，補實際瀏覽器或者操作驗證。各種證據各有範圍。

4. 覆蓋率門檻點用先有意思？

先用專案現有框架產生報告，確認量度嘅檔案、排除項目同指標。Statements、branches、functions、lines 唔係同一樣嘢，唔同測試命令嘅選項亦唔通用。

門檻可以防止重要模組嘅測試覆蓋突然下降，但應該連同具體行為要求使用。例如：

測試政策範例：
- 修改權限判斷時，要驗證允許、拒絕與跨帳戶隔離。
- 修正可重現錯誤時，保留對應回歸測試。
- 改動匯入器時，要驗證重複資料、部分失敗與再次執行。
- 覆蓋率下降時，解釋原因，唔以排除程式碼掩蓋下降。
- 排除產生檔案等量度雜訊，要有明確理由。

團隊可以按現況定數值基線，再逐步改善；唔好為達到一個漂亮數字寫無意義斷言，或者刪走難測分支。

5. 留返一份可追查結果

完成一輪後，記低改咗咩行為、加咗咩案例、用咩命令驗證、結果係點，同仲有咩未知。

測試通過唔等於正式環境必然安全。相反，冇自動測試亦唔一定代表每個文字改動都要新增測試；要揀能有效發現今次錯誤嘅方法。重點係驗證同風險對得上，而唔係每個檔案都用同一把尺。