我測量了AI編寫空心測試是否比人類更嚴重，結果並非如此

在現代軟體開發中，自動化測試、型別檢查和持續整合（CI）門禁被視為保障程式碼質量的重要防線。然而，這些防線本身也可能存在缺陷——它們可能看似存在並且執行正常，但實際上從未驗證任何東西。這種“空心”守衛比完全沒有守衛更加危險，因為它們給人一種虛假的安全感。最近，一位開發者透過分析一個程式碼倉庫，發現了七個這樣的空心守衛，並由此開發了一個新的開源工具voidguard，專門用於檢測這類問題。

voidguard能夠識別四種型別的空心守衛。第一種是“從未執行的測試”，這些測試被環境標誌或CI配置跳過，但實際上沒有在任何地方真正執行。第二種是“不檢查任何東西的型別門”，例如配置錯誤的mypy或tsconfig，它們聲稱正在執行型別檢查，但由於配置缺陷實際上沒有檢查任何有效程式碼。第三種是“被靜默丟棄的設定”，比如在Python指令碼中設定的PYTHON*變數被命令列引數覆蓋而失效，或者在Docker構建中定義的ARG在錯誤的位置被使用。第四種是“永遠無法觸發的CI條件”，例如CI工作流的觸發條件引用了永遠不會發生的事件，或者計劃任務從未成功執行。對於每種檢測到的空洞，voidguard會給出一個明確的判定：VOID（空洞）、WARN（警告）或UNKNOWN（無法確定），並附帶詳細的搜尋範圍資訊。

儘管voidguard很強大，但它並非萬能。作者明確指出，該工具無法檢測三種型別的空洞。首先是“語義空洞”，例如一個欄位型別被標記為可空但實際從未被寫入值，或者一個函式返回null但呼叫方將其當作有效值。這類問題需要型別流或資料流分析，而不僅僅是檔案結構分析。其次是“流程空洞”，例如一個需要人工審批的步驟在合併過程中被繞過，而所有自動化檢查都顯示為綠色。沒有任何掃描工具能夠捕捉到這種人為決策的缺失。最後是“需要執行才能發現的空洞”，voidguard本身從不執行程式碼，所以它無法發現那些在執行時才會暴露的錯誤。當靜態分析無法確定時，voidguard會誠實地返回UNKNOWN並解釋原因，因為一個聲稱發現空洞卻自己產生誤報的工具本身就是一個空心守衛。

voidguard的誕生源於一個具體的案例。在一個倉庫的一次性掃描中，作者發現了七個空心守衛：一個核心完整性測試從整合開始就默默地被跳過，一個型別檢查門禁實際上沒有檢查任何內容，一個審批步驟被合併操作直接繞過。所有這些守衛的CI狀態都是綠色的，但它們的實際驗證效果為零。voidguard正是這種掃描方法的通用化實現。這個工具已經發布在PyPI上，原始碼也在GitHub上公開。它不僅是一個實用的檢測工具，更傳達了一個重要的理念：在自動化測試和驗證中，我們必須驗證驗證本身的有效性，否則那些綠色狀態只能帶來虛假的安全感。