你的單元測試是否優秀？來測驗一下吧~

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

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

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

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

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

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

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

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

盡管我不相信每個項目都應該為測試使用一些花哨的命名約定，但合理的命名能夠通過隻讀失敗的測試用例的名稱來判斷代碼的哪一部分被破壞了。

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

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

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

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

歡迎加入我的軟體測試交流群：785128166，裡面不定時分享測試資源，還有同行大佬一起交流學習！

​