成本感知的測試驗證
減少重複工作與不必要的輸出，同時不削弱必要的檢查。選擇更佳的順序可以節省執行時間；精簡的報告能節省上下文，但不會讓已執行的測試變快。未經測量，請勿宣稱節省了成本。
規劃與執行檢查
- 在執行昂貴的測試套件前，先識別受影響的元件、風險、專案需求以及適當的檢查。遵循使用者與專案的明確要求，包含強制檢查。
- 先完成核心變更與有意義的目標迴歸覆蓋。針對建置或行為失敗，以最狹義的相關檢查進行診斷與修復。接著穩定受影響的整合或端對端情境。對於新增或變更的共享情境，將預期結果與可用的參考進行比對；分別驗證並記錄非預期的差異。
- 一旦變更與目標檢查穩定後，根據情況執行所需的最終測試套件、靜態檢查與建置。僅在相關程式碼、相依套件、設定、環境與情境未改變時，重用先前成功的結果。
- 修正後，重新執行受影響的檢查。當影響範圍廣泛、相依套件變更、需求要求或正確性仍不確定時，才重複執行廣泛的測試套件。不要對每個本地失敗都自動重跑完整套件。
- 對於間歇性失敗，保留首次失敗並單獨重跑該測試；必要時以序列方式執行其測試套件以調查干擾。報告未解決的不穩定性，而非將後續通過的測試視為失敗已修復的證據。
- 對於僅文件變更，檢查 diff、相關連結與語法；僅在要求或相關時執行應用程式測試。保持效能度量與可能扭曲結果的並行建置及測試隔離。
- 以合理的間隔輪詢長時間運行的作業，而非重複讀取未變更的輸出。避免僅為了檢查進度而重新啟動工作。
保持輸出有用且可控制
優先使用專案既有的執行器或框架報告功能。在適當情況下，將完整的標準輸出與標準錯誤擷取到一個獨一無二、不會覆蓋的日誌，並回傳簡潔的摘要：命令結果與退出狀態、執行時間、可識別的測試計數（包含跳過或忽略的測試）以及日誌位置。失敗時，包含失敗的案例名稱與有邊界的診斷摘錄；若摘要資訊不足，再檢查完整日誌的相關部分。絕不根據部分測試套件的計數推斷整體成功與否：請使用命令的實際退出狀態，並在無法解析摘要時明確說明。保留啟動錯誤、取消與訊號行為。不要在不存在的執行器上堆疊多餘的包裝層。
驗證測試基礎設施
當建立或大幅修改測試執行器、包裝層或報告工具時，請測試其結果的可信度。根據工具實際所做的工作以及隱藏或誤報失敗的風險來選擇測試案例。有用的案例包含：
- 在成功的測試套件之後發生的後續失敗仍應視為失敗，並帶有正確的退出狀態。
- 即使顯示的診斷有邊界限制，完整的輸出仍應保留。
- 跳過、啟動錯誤、無法辨識的摘要以及中斷事件，應在適用情況下正確回報或傳播。
測試可觀察的行為，包含與底層測試進程的邊界。根據實際的框架調整解析方式，並避免僅是複製實作內容的測試。這是對基礎設施的驗證，而非要求為每個個別測試撰寫測試。不要僅因使用了此技能就重寫或重新測試可靠且現有的工具。
撰寫診斷測試
讓通過的測試保持安靜，除非進度輸出有其價值。失敗時應識別案例、預期與實際行為、相關參數以及任何隨機種子。針對大型負載，描述其長度、不匹配位置、簡短摘錄或雜湊值，而非傾印所有資料。必要時啟用每次迭代的詳細資訊或完整追蹤以進行診斷。明確標記跳過並附帶原因，絕不將失敗轉換為成功退出。當正在處理現有不穩定的測試時才改善其噪音，而非僅為了格式化而重寫一個健康的測試套件。