優質單元測試的十大標准，你有遵循嗎？
原創
最后编辑：李晓琳 于 2020-10-15 15:22:36
1719次查看
本篇目錄
優秀的測試套件可以讓人在更改代碼時感到安全，從而使工作更爲輕松；糟糕的測試套件會讓人痛苦不堪，且浪費大量時間。編寫好的、可維護的單元測試存在著一些特定規則，可使單元測試質量更高、更具效率。
1、盡可能簡短
因爲我們測試的是由單個代碼單元交付的單個功能，所以測試應該相當短是有意義的。至于具體需要多短就取決于多種因素，但通常不會超過幾行代碼。2、切忌自我重複
良好的编码实践应用于测试代码的方式与应用于生产代码的方式相同。从实践经验上来说，单元测试中最容易违反的规则之一是“Dont Repeat Yourself”。有些人甚至声称单元测试根本不应该共享任何代码。那是全然的废话。当然，我们希望尽可能保持测试的可读性，但是复制粘贴不是解决方案。3、選擇組合而非繼承
一旦了解了前面的两点，你可能会想要为自己的测试创建一些包含常用代码的基类。如果确实如此，请立马停止！这样的基类就像磁铁一样吸引着各种不相关的共享代码，并且增长非常迅速，直到接管你的项目、迭代、産品……为保证这些不被它逐步侵蚀，务必使用组合方式！4、使其速度更快
單元測試幾乎可以一直運行。出于這個原因，一定要模擬外部依賴項和其他可能會減慢測試速度的東西，這通常是數據庫、外部系統或文件操作。同時，不要做得太過——完全隔離被測單元也不是一個好的解決方案。5、使其具有確定性
每當聽到有人擁有了95%的可用測試套件，並認爲這已經足夠好到可以投入生産時，我總是哭笑不得，因爲單元測試應該必須保證100%可工作性。只有100%通過測試才意味著一切正常（對于單元，您還需要其他類型的測試）。如果你的單元測試看起來不可靠，請確保找到根本原因並盡快修複它。6、不要爲測試標注“可忽略”
在第四條和第五條的基礎上，必須要提及的是給測試添加“可忽略”注釋，這並不是修複測試套件的方法，反而會使測試套件更加不可靠，因爲它並不能避免回歸Bug之類的問題。7、測試你的測試
這一條不是說爲你的測試編寫測試，而是指進行如突變測試、測試驅動開發或頻繁地在代碼庫中“隨機更改東西”這樣的實踐，以查看是否有測試失敗。還可以經常做一些腦力練習，試圖找出自己的測試中無法發現的對代碼的潛在更改。8、合理命名測試
盡管我不相信每個項目都應該爲測試使用一些花哨的命名約定，但合理的命名能夠通過只讀失敗的測試用例的名稱來判斷代碼的哪一部分被破壞了。9、每個測試僅包含一個邏輯斷言
爲了實現僅僅通過讀取失敗測試的名稱就可以判斷出錯誤的目標，需要的不僅僅是好的名稱。一個測試檢查也必須限制一些事情。因此，一個好的單元測試應該只包含一個邏輯斷言，即只檢查被測試方法的一個輸出/副作用。10、設計你的測試
這是一個元技巧，它涵蓋了本文中所有其他技巧以及在這裏沒有提到的技巧。對待測試要像對待/編寫代碼一樣謹慎。考慮良好的設計原則和指標，如測試代碼和生産代碼之間的低耦合，以及代碼的重複、死代碼等。
請記住，一個好的測試套件可以使您在更改和重構代碼時感到安全，從而使您的工作更加輕松，而糟糕的測試套件則會使您痛苦不堪，浪費大量的時間，並使代碼幾乎不可能更改。
DevOps幹貨
