前言：為什麼寫這個系列

我自己維護 omnipay-ecpay 這個公開套件已經好幾年，一直有個念頭：這套件的品質防線到底可不可靠，我其實從來沒有認真盤點過。CI 綠燈亮著就當作沒事,覆蓋率報表設定在那裡但從來沒點開看過真實數字，check-style 這個 script 我自己都忘了它存在。藉著鐵人賽當推力，強迫自己把這些「應該還好吧」的假設,一項一項攤開來核對——這是這個系列真正的起點,不是先有一個漂亮的方法論才動筆，是先有一堆沒人回頭檢查過的角落。

分階段回顧

第一部（Day 1-7）：認識這個套件與它的測試現況
從 README 沒跟上程式碼講起，看 Trait 怎麼組合出 12 種付款方式的欄位、HasECPay 怎麼把官方 SDK 包進 Omnipay 的統一介面、21 個自己寫的測試方法加上 26 個從官方 GatewayTestCase 繼承來的泛用測試共 47 個測試的真實分布、Stub 而非 Mock 的測試替身選擇，最後停在「覆蓋率設定了但 CI 用 --no-coverage 關掉」這個發現。

第二部（Day 8-14）：一筆 commit 看透「補測試」的真實節奏
拆解 commit 80d3469，發現它真正新增的程式碼只有 15 行（getBNPLFields()），但測試新增了 139 行——代表這次是「加新功能時，順手把 ATM、彈性分期這兩條早就存在但沒被測到的舊路徑也一併補上」。對照 RefundRequest/VoidRequest 至今仍只有各 1 個 happy-path 測試,討論制度（覆蓋率門檻）跟自覺（開發者當下有沒有想到）,哪個更靠得住。

第三部（Day 15-22）：跨版本相容性與靜態品質把關
composer.json 沒宣告 PHP 版本、README 徽章連到早就沒人用的 Travis/Scrutinizer、在暫存複本上第一次跑 PHPStan 抓到 7 個錯誤（包括一個把 string 打成 stirng 的烏龍）、check-style 從未接進 CI，實測發現 8 個 PSR2 違規,還有一個意外的重量級發現：composer audit 顯示依賴鏈累積了 17 個安全性風險通報。

第四部（Day 23-29）：把踩坑收斂成可重複的品質防線
在暫存複本上實際動手：示範覆蓋率門檻的設定思路、把 check-style 接進 CI 的 YAML 示範跟既有違規的取捨、幫 RefundRequest 補一個 13 行的例外測試、寫一段可以放進 CLAUDE.md 的 prompt 規則。最後誠實盤點這些補救動作,哪些是示範用途,哪些真的需要另外評估才能推回公開套件。

個人心得：這次示範,我自己也卡在哪裡

如果要誠實講，這次系列有兩個地方我自己也沒有處理得很漂亮。

第一個是 coverage driver 裝不起來這件事——Day 07、18、23 反覆提到,本機環境沒有 pcov/xdebug，嘗試用 pecl install pcov 安裝失敗，卡在系統缺少 pcre2.h 這個編譯依賴。我原本以為「補一個覆蓋率門檻」是這個系列裡最直觀、最容易展示成果的一天,結果反而是卡最久、最後只能誠實寫「示範做法，沒辦法展示真實跑出來的數字」的一天。這其實剛好示範了品質工具本身的一個現實：連要把工具正確裝起來，都不是零成本的事——這不是我事先設計好的教學橋段,是真的卡住了才寫進文章裡。

第二個是要不要真的把這些補救動作推回公開套件這個猶豫。Day 29 已經誠實列出來：phpcs 命名慣例的取捨（要不要為了符合 PSR2 犧牲跟綠界官方文件一致的欄位命名）,是一個我自己現在都還沒拿定主意的設計決定。這個系列選擇不假裝已經決定好，而是把猶豫本身寫出來——維護一個被別人依賴的公開套件，很多決定不是技術對錯的問題，是要不要承擔後續影響的問題,這件事沒有一次示範就能講清楚。

回到時代命題：AI 時代的測試品質防線,到底靠什麼撐住

這 30 天反覆出現的一個模式是：這個套件不是沒有品質工具，是工具擺在那裡沒有真的被用起來守門。覆蓋率報表設定存在但沒人看、check-style 定義了但沒接進 CI、PHPStan 從來沒被裝過、composer audit 從來沒被想到要跑。這些工具沒有一個是新奇或難裝的東西，它們沒被用起來的原因,通常不是技術障礙，是沒有人在某個時間點停下來想「我們現在還缺什麼」。

放到 AI 協作的脈絡下，這件事的意義更清楚：AI 可以幫你補程式碼、補測試、甚至幫你裝好 PHPStan 設定檔,但它不會自動知道你的專案裡有哪些「應該還好吧」的假設,從來沒被驗證過。AI 能回答「怎麼做」，回答不了「你到底缺什麼」——這個問題永遠需要一個人先停下來,像這個系列做的這樣,一項一項核對現況,才會浮現出來。這正是這個系列從 Day 01 就立下、貫穿全系列的主題句：AI 能幫你補程式碼，但補不出你自己都沒發現的測試缺口。

給讀者的具體建議

如果你看完這個系列想做點什麼，這裡是幾個立即可行、不需要很多時間的第一步：

1. 現在就跑一次 composer audit（或你的語言生態系的等效指令）——這個系列裡最讓我意外的發現,就是這個幾乎零成本的指令,一跑就冒出 17 個累積已久的安全性風險。
2. 打開你的 composer.json／package.json，看有沒有定義了但從沒被 CI 呼叫過的 script——像這次的 check-style 一樣，被遺忘的工具往往就藏在你自己寫過的設定檔裡。
3. 挑一個你覺得「反正很簡單，應該早就測過了」的方法，實際去確認測試涵蓋的情境——這個系列的 RefundRequest/VoidRequest 就是活生生的例子。

結語：品質防線要自己蓋

Day 01 那句話，寫到這裡想重新講一次：維護一個公開套件跟接手一套內部系統，最大的差別是你看不到誰在用它。你補的每個測試、關掉的每個覆蓋率警告，都是在替一群你素未謀面的使用者把關。 這 30 天不是要證明這個套件有多完美——事實正好相反,它有覆蓋不均的測試、被遺忘的 phpcs、累積的安全性風險、跟脫鉤的 README 徽章。這個系列想證明的是另一件事：這些破洞不用靠一次大掃除解決,只要願意一天一天、一項一項核對現況,品質防線是自己一磚一瓦蓋起來的，不是等 AI 或任何工具幫你決定該蓋在哪裡。

謝謝你看完這 30 天。