OxideTerm 測試審計 是做什麼的？
將有用的迴歸保護保留在擁有該行為的層級。使用能解決所請求變更的最小審查規模；根據所保護的契約與檢測到的錯誤來判斷結果，而非測試數量或刪除的行數。
閱讀適用的 AGENTS.md。從儲存庫根目錄執行指令。驗證矩陣與測試指南定義了專案特定的檢查項目；此技能則提供測試品質相關的決策。
選擇範圍
- 撰寫或修改測試： 針對該行為套用撰寫問題，並檢查其最接近的現有覆蓋範圍。
- 診斷失敗： 在編輯之前，先確定測試失敗的原因，是實作、預期值、測試夾具 (fixture) 還是環境的問題。
- 審計現有測試： 審查所請求的模組或行為，並為每個提議的變更記錄證據。僅在明確要求時才擴展到整個子系統。每個批次的證據標準應保持一致。
建立或調用此技能並不授權進行大規模清理、使用子代理、提交、推送或建立 PR。請尊重使用者既有的授權範圍以及任何僅供審查的限制。當編輯已獲授權且證據充足時，無需再經一輪審批即可繼續。
撰寫問題
在新增或修改測試之前，請先確認：
- 正在保護的可觀察行為或獨立契約。
- 一個合理的迴歸案例以及它會導致哪個特定的斷言失敗。
- 最接近的現有覆蓋範圍遺漏了什麼。在適當的情況下擴展該覆蓋範圍；另一個層級需要不同的整合、通訊協定或生命週期風險。
- 該測試是否需要一個沒有商業呼叫者的生產環境匯出、開關、包裝器或注入鉤子。優先測試現有擁有邊界上的行為。
使用獨立於實作的預期值。測試夾具必須能夠區分正確行為與可能的錯誤：測試過濾器時應包含被排除的候選項，測試排序時應使用不同的排序鍵，檢查資料遮罩時應使用實際的敏感輸入。僅有建構子欄位的往返測試、非空結果，或是模擬了被斷言行為的 mock，都不足以證明預期的工作流程。
測試輔助函式和測試夾具可以合理地僅供測試使用。需要關注的是扭曲生產 API，或是僅為了測試而保留已過時的生產行為。
診斷失敗的測試
閱讀完整的測試、其輸入、對應的生產路徑、附近的覆蓋範圍以及相關的變更歷史。對於 CI，請確定失敗的提交、工作、測試名稱和斷言；僅有非零退出碼並不能指出根本原因。當斷言依賴於相依套件的行為時，請檢查其原始碼或型別定義。
根據證據對失敗進行分類：
- 產品迴歸： 預期的契約仍然有效。重現失敗，並在授權範圍內修復擁有該行為的實作。
- 過時的預期： 歷史記錄和當前的契約顯示行為已遭有意的變更。更新預期行為，同時保留對已支援的發行版格式和 API 的保護。
- 測試或夾具錯誤： 測試案例並未實際執行其所聲稱的條件，依賴於偶然的狀態，或因無關原因失敗。在實際邊界上修復設定和斷言。
- 環境失敗： 編譯、依賴項、資源、平台或外部夾具導致無法測試該行為。回報該限制；不要將其重新解釋為一個通過或過時的測試。
基準測試 (baseline) 的失敗並非刪除測試的理由。對於錯誤修復，請在修復前展示預期的失敗，並在修復後展示成功。當能證明同一種失敗時，可重複使用有效的 CI 證據或捕捉到的本地基準測試；不要僅為了形式而重複執行昂貴的檢查。
例如，.oxide 插件測試需要區分無密碼驗證與已解密的匯入預覽。加密格式的驗證回應不應洩露元資料；而包含密碼的預覽則應仍然包含明確預期的描述和連線名稱。更新這些斷言可以保留契約，無需在插件層級再進行一次低階的解密測試。
審計前先編輯
完整閱讀每個候選測試，包括其參數列。追蹤其生產入口點、呼叫者、相關依賴項、兄弟實作以及重疊的測試。檢查歷史記錄以了解其存在的原因，以及 CI 路由以確定哪些檢查會實際執行。
對於提議的變更，請在工作回應中使用簡潔的證據記錄（除非要求儲存報告）：
| 測試與位置 | 行為與可信的失敗 | 決策 | 剩餘或已修復的證明 | 驗證 |
|---|---|---|---|---|
| 確切的測試名稱與路徑 | 斷言可以檢測到的內容 | 保留 / 修復 / 合併 / 刪除 | 具名測試或邊界，附上相關歷史 | 聚焦的指令或手動情境 |
- 保留： 獨立保護了一個有意義的契約。
- 修復： 該行為很重要，但其輸入、斷言、名稱或預期結果錯誤或過於薄弱。
- 合併： 在刪除重複的設定或案例之前，將不同的斷言移至指定的主要測試中。
- 刪除： 指出其餘更強的證明，或證明該行為不再有支援的契約。不確定則應調查或保留。
對於與測試一起刪除的生產程式碼，也請找出其非測試的呼叫者，並說明該程式碼為何已過時。在刪除輔助函式、匯出、功能或夾具前，請先搜尋其引用。請勿將無關的簡化納入審計的一部分。
值得調查的模式
- 測試重複了實作原始碼、私有呼叫形式或確切的內部表示，並且在行為保留的重構後失敗。
- 數個層級使用等效輸入呼叫同一個輔助函式，並重複其斷言，而未實際測試它們自身的整合。
- 一個夾具預先安排了回呼順序、完成通知或持續化結果，而這些本應由實際的擁有者產生。
- 一個拒絕測試在達到其聲稱要測試的權限檢查之前，就被參數驗證拒絕了。
- 一個並發、取消或喚醒測試僅檢查最終的旗標，而沒有建立競爭的工作或等待者。
- 一個成功斷言僅檢查
Ok、Some、長度或非空，而內容、身份、順序或持久性副作用才是契約。
這些是調查的信號，而非自動刪除的規則。請保留獨立的安全預設值、通訊協定位元組、持久化與遷移格式、插件 API、平台行為、套件封裝、國際化以及架構限制。當靜態檢查能防護真實的契約，並且能在無關的重新命名下存活時，它可能是有用的。執行緩慢本身並不會使測試變得多餘。
OxideTerm 邊界
| 行為 | 偏好的驗證邊界 |
|---|---|
| 語法解析、設定正規化、序列化或資料合併 | 擁有該領域的 crate，使用明確的預期值和支援的格式樣本 |
| SSH 節點共享、SFTP、轉發、重新連線或跳板主機 | 執行時期的擁有者，搭配實際的消費者註冊、取消和清理；請參閱執行時期擁有權 |
| 混合頁面、焦點、彈出視窗或延遲的 UI 結果 | 現有的 GPUI 測試上下文和功能實體；原生的 IME、視窗和 GPU 行為仍需主機驗證 |
| 插件、MCP 或 CLI 適配器 | 實際的分派與返回資料、權限、目標身份或副作用；避免單獨重播領域輔助函式 |
| 資料遮罩與憑證生命週期 | 透過相關的輸出或擁有權邊界傳遞合成秘密輸入；請參閱敏感資料 |
| 套件封裝與儲存庫腳本 | 現有的腳本測試，或由驗證矩陣選擇的實際乾執行 (dry-run) 契約 |
對於共享節點測試，關閉一個終端機應使另一個真實消費者仍可使用。對於處理過時結果，應在擁有者變更後傳遞舊的完成事件。使用現有的夾具和事件驅動的同步；任意的 sleep 和多餘的重試無法建立這些條件。
驗證並完成
在開始測試執行之前，先完成相關的來源/測試編輯。在測試執行期間保持結出的版本穩定。
- 執行聚焦的測試或模組，例如
cargo test -p <crate> <test_filter>。使用實際擁有該目標的平台和目標；桌面測試位於oxideterm-gpui-appcrate 的oxideterm-native二進位目標中。獨立的遠端代理使用--manifest-path agent/Cargo.toml。 - 讀取結果並驗證預期的測試已實際執行。零個匹配測試的成功指令不算是證明。在刪除或移動後，請執行其餘的具名覆蓋範圍以及任何受影響的不同整合檢查。
- 對於 Rust 編輯，執行
cargo fmt --check和git diff --check。根據驗證矩陣，加入 crate 檢查、腳本測試、區域審計或手動工作流程。重用結果，直到相關變更或新的證據使其失效。 - 審查最終的 diff 和狀態。檢查是否沒有任何獨特的行為消失、沒有任何斷言被弱化以隱藏產品失敗，以及沒有任何無關的工作被修改。
僅在需要解決對某個斷言的具體疑問時，才使用刻意變異 (deliberate mutation)。使其與使用者的工作隔離，事後準確還原原始碼，且不要求每次測試都執行。子系統範圍的審計應在執行最終受影響的測試套件之前，將被刪除的案例與其餘的具名測試進行比對。
報告決策、仍受保護的行為、實際執行的檢查以及任何重大的未驗證邊界。當發生刪除時，應解釋被刪除的覆蓋範圍。當所請求的範圍完成時即停止；不要為了滿足數字或減量目標而擴大審計範圍。
來源
改編自 OpenClaw 的 test-audit 和 campaign guidance 中的測試價值與證據原則。此處的執行、擁有權和驗證遵循 OxideTerm 的儲存庫規則。