優秀的測試套件可以讓人在更改程式碼時感到安全，從而使工作更為輕鬆；糟糕的測試套件會讓人痛苦不堪，且浪費大量時間。編寫好的、可維護的單元測試存在著一些特定規則，可使單元測試質量更高、更具效率。

1、儘可能簡短

因為我們測試的是由單個程式碼單元交付的單個功能，所以測試應該相當短是有意義的。至於具體需要多短就取決於多種因素，但通常不會超過幾行程式碼。

2、切忌自我重複

良好的編碼實踐應用於測試程式碼的方式與應用於生產程式碼的方式相同。從實踐經驗上來說，單元測試中最容易違反的規則之一是“Dont Repeat Yourself”。有些人甚至聲稱單元測試根本不應該共享任何程式碼。那是全然的廢話。當然，我們希望儘可能保持測試的可讀性，但是複製貼上不是解決方案。

一旦瞭解了前面的兩點，你可能會想要為自己的測試建立一些包含常用程式碼的基類。如果確實如此，請立馬停止！這樣的基類就像磁鐵一樣吸引著各種不相關的共享程式碼，並且增長非常迅速，直到接管你的專案、迭代、產品……為保證這些不被它逐步侵蝕，務必使用組合方式！

單元測試幾乎可以一直執行。出於這個原因，一定要模擬外部依賴項和其他可能會減慢測試速度的東西，這通常是資料庫、外部系統或檔案操作。同時，不要做得太過——完全隔離被測單元也不是一個好的解決方案。

每當聽到有人擁有了95%的可用測試套件，並認為這已經足夠好到可以投入生產時，我總是哭笑不得，因為單元測試應該必須保證100%可工作性。只有100%透過測試才意味著一切正常（對於單元，您還需要其他型別的測試）。如果你的單元測試看起來不可靠，請確保找到根本原因並儘快修復它。

在第四條和第五條的基礎上，必須要提及的是給測試新增“可忽略”註釋，這並不是修復測試套件的方法，反而會使測試套件更加不可靠，因為它並不能避免迴歸Bug之類的問題。

這一條不是說為你的測試編寫測試，而是指進行如突變測試、測試驅動開發或頻繁地在程式碼庫中“隨機更改東西”這樣的實踐，以檢視是否有測試失敗。還可以經常做一些腦力練習，試圖找出自己的測試中無法發現的對程式碼的潛在更改。

儘管我不相信每個專案都應該為測試使用一些花哨的命名約定，但合理的命名能夠透過只讀失敗的測試用例的名稱來判斷程式碼的哪一部分被破壞了。

為了實現僅僅透過讀取失敗測試的名稱就可以判斷出錯誤的目標，需要的不僅僅是好的名稱。一個測試檢查也必須限制一些事情。因此，一個好的單元測試應該只包含一個邏輯斷言，即只檢查被測試方法的一個輸出/副作用。

這是一個元技巧，它涵蓋了本文中所有其他技巧以及在這裡沒有提到的技巧。對待測試要像對待/編寫程式碼一樣謹慎。考慮良好的設計原則和指標，如測試程式碼和生產程式碼之間的低耦合，以及程式碼的重複、死程式碼等。

請記住，一個好的測試套件可以使您在更改和重構程式碼時感到安全，從而使您的工作更加輕鬆，而糟糕的測試套件則會使您痛苦不堪，浪費大量的時間，並使程式碼幾乎不可能更改。

以上十個標準不一定需要全部遵循，可根據團隊、個人情況進行選擇性取捨。

作者：陳琦，資深敏捷測試顧問，作為國內知名專案管理軟體—— 的團隊成員，主要負責開源自動化測試管理框架——ZTF的開發工作。擁有十多年的敏捷過程實踐經驗，現致力於測試自動化和DevOps相關領域的實踐和研究。