我測量了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上公開。它不僅是一個實用的檢測工具，更傳達了一個重要的理念：在自動化測試和驗證中，我們必須驗證驗證本身的有效性，否則那些綠色狀態只能帶來虛假的安全感。