遺留系統的測試策略

遺留系統常見的棘手狀況是程式已經運作多年，測試沒有完整記錄它的行為。需求文件可能缺漏，原作者也未必還在團隊裡。

這時若直接請 Codex 整理程式或修正邏輯，修改看似合理，仍可能改掉使用者早已依賴的細節。

因此在動手修改前，要先補上系統的測試。補測試可以分成兩個階段。第一階段先建立特徵測試（Characterization Test），把目前可觀察到的輸入與輸出記錄下來。第二階段再依照已確認的需求，加入具有業務語意的測試。

特徵測試提供修改前的基準，業務測試說明系統應該遵守的規則。

遺留程式缺少的是行為證據

看到一段沒有測試的函式時，開發者會根據函式名稱、註解或程式結構推測它應該做什麼。

這些線索值得參考，卻不等同於完整規格。實際輸出還可能受到呼叫端、資料格式、預設值與歷史相容需求影響。

因此，第一輪先請 Codex 探索呼叫路徑、現有測試慣例與可觀察結果。

任務範圍要小，例如鎖定一個函式、一個分支或一種輸入資料。若一次涵蓋整個模組，產生的測試可能混合多項行為，之後很難判斷是哪一條規則發生變化。

開始前也要確認目標確實沒有直接測試。Codex 可以搜尋函式名稱、測試資料與相似案例，列出它找到的證據。

若已有測試，就先說明缺口。若無法確定規格，就停在觀察與報告，不替團隊補上猜測。

特徵測試先記錄目前行為

特徵測試的工作是固定現況。它可能記錄正常輸出、特殊排序、例外型別，甚至一項看來不理想的歷史行為。

測試通過只代表描述與目前程式一致，不表示該行為已經獲得產品或業務確認。

建立這類測試時，先用既有介面送入一組最小資料，再觀察回傳值、狀態變化或錯誤。

Codex 應把觀察結果寫成測試，沿用專案既有的測試框架與命名慣例，並執行最小相關測試套件。提示詞（Prompt）的寫法應包含目標行為、相關程式、限制條件與驗證方式。

斷言只固定和目標行為有關的內容。整份快照若包含時間戳記、暫存路徑或無關欄位，後續就可能因雜訊失敗。

可採用的做法是挑出可觀察且有意義的結果，例如回傳陣列順序、錯誤類型或幾個關鍵欄位。

可以先給 Codex 這段任務：

請先閱讀與 issue labels 正規化相關的實作、呼叫端和既有測試。
確認「輸入資料缺少 labels 欄位」是否已有直接測試，並列出搜尋證據。

若沒有直接測試：
1. 用最小輸入重現目前行為。
2. 先不要修改正式程式碼。
3. 依現有測試慣例加入一個 Characterization Test，忠實記錄目前可觀察結果。
4. 只斷言與缺少 labels 有關的穩定結果。
5. 執行最小相關測試，回報命令與結果。

若已有直接測試，或無法安全重現，請停止修改並說明原因。

業務測試把需求寫成可判定的規則

完成現況記錄後，開發者再把需求轉成業務測試。

測試名稱應說明使用情境與預期結果，例如「沒有標籤的議題會列為未分類」。輸入資料只留下判斷該規則所需的最少欄位。讓閱讀者不必先理解內部函式，就能從測試看出產品承諾。

這次我們練習使用以下規則：議題缺少 labels 欄位時，系統將它視為未分類。處理過程不能拋出錯誤，bug、feature、documentation、security 四種統計都不增加，而且該議題仍須保留在排名結果中。這段規則由開發者提供，Codex 只能協助轉寫為測試。

接著給 Codex 第二段任務：

在剛才的 Characterization Test 之外，再加入一個獨立的業務測試。

已確認的業務規則：
- issue 缺少 labels 欄位時，視為未分類。
- 不得拋出錯誤。
- bug、feature、documentation、security 的統計都不得增加。
- 該 issue 仍須保留在排名結果中。

請使用能表達上述情境的測試名稱，並採用最小測試資料。
先不要修改正式程式碼，也不要改寫 Characterization Test 來迎合新規則。
執行最小相關測試，分別回報兩個測試的結果；若業務測試失敗，請指出實際結果與規則的差異。

兩個測試可能同時通過，也可能出現特徵測試通過、業務測試失敗的結果。

後一種情況提供了明確資訊，表示程式現況和已確認需求存在差距。此時保留失敗的業務測試與執行紀錄，待團隊決定後續修改範圍，不要讓 Codex 自行改變斷言以取得綠燈。

人工審查要確認測試真的在表達需求

Codex 適合搜尋現有慣例、準備測試資料、撰寫斷言與執行命令。測試案例的意義仍由開發者負責確認。

先看測試名稱能否說清楚情境，再檢查輸入是否代表真實資料，最後逐項核對預期結果是否來自已確認的規則。

特徵測試還要多問一層：它記錄的是穩定的外部行為，還是偶然的內部實作細節？

若測試直接綁定私有函式、排序過程中的中間值或過長快照，輕微重構就可能使它失效。優先從公開介面觀察結果，才可以留下可靠的保護網。

審查業務測試時，不要只看它能否通過。確認測試先在缺少對應行為時失敗，能增加它確實攔截缺陷的可信度，再檢查通過後是否仍可能漏掉關鍵結果。

必要時可暫時改動一個條件，證明測試會對錯誤行為發出警報，完成後再還原。

補上測試的實際流程

今天我們針對「議題資料缺少 labels 欄位」這段未受直接測試保護的既有邏輯，先建立一個特徵測試，再加入一個具有明確業務語意的測試。

執行前仍要讓 Codex 查證目前專案狀態。若該行為已經有直接測試，就停止修改並回報，不要自行換成另一項任務。

交付時應能清楚看到兩個案例：一個忠實記錄執行當下的現況，一個表達「未分類議題仍須安全處理並保留在排名中」的需求。

最後由開發者閱讀差異（diff）並確認測試意圖。若業務測試失敗，我們的任務仍可視為完成，因為它已把需求缺口轉成可重現的證據。

正式程式的修正應另開一個範圍清楚的任務，並以這兩個測試作為修改前後的比較基準。