老李分享：單元測試的 5 個錯誤 老李分享：單元測試的 5 個錯誤

老李分享：單元測試的 5 個錯誤

 

當我第一次據說可使用框架好比JUnit來進行單元測試的時候，我驚歎這真是一個簡單而強大的概念。它取代了隨機測試，使你能夠保存你的測試代碼，並按照須要隨時運行它們。按照個人理解，關於單元測試並無多少產生誤解的可能。可是過去的幾年中，我確實見過幾種或多或少不太正確的單元測試使用方式。這裏按照重要程度，列出5條:

 

1. 跟協做邏輯一塊兒來測試算法。若是跟協做邏輯代碼分離開來，那麼算法邏輯是最容易測試的(參見選擇性單元測試 – 代價和好處)。不然在你的邏輯被測試以前，你就不得不先進行諸如經過任務隊列提交一個任務之類的工做。 任務隊列部分只會使事情變得複雜。除非你想測試任務隊列自己，不然你就應當把調用run方法時所執行的邏輯剝離開來，並對它進行單獨測試。那樣，不管是編碼仍是測試都會更易於編寫和管理。

2. Mock測試太多。也許單元測試的最大好處就是它迫使你編寫可以獨立測試的代碼。也就是說，你的代碼會變得模塊化。當你把你要處理的對象的周圍的一切都模擬了，就沒有什麼能迫使你去把各部分分離開來。你會發現這樣寫出的代碼，你很難在外圍添加獨立的部分 – 由於全部東西都糾纏在一塊兒。Bill Wake最近發推說: 」真是諷刺 – 模擬測試框架越強大，你在改進設計時所感覺到的壓力就會越小。」

3. 不使用斷言。有時我會看到一些測試，裏面建立了一個對象，調用了一些方法，而後，就沒有而後了。也許它是在循環裏這樣作的，並且在建立和調用上會有些差別。可是，卻沒有用斷言來作任何檢查。這就徹底失去了意義 – 沒有檢查你的代碼是否按照預期進行工做的。固然，代碼是運行了，可是僅此而已。若是拋出了一個異常，咱們會注意到它，可是卻不會驗證其它任何事情。

4. 在測試代碼中遺留print語句。我把這視爲手工測試的後遺症 – 你但願看到對象的值來判斷它們是否正確。可是全部的檢查都應當使用斷言來完成。若是單元失敗了，你也能看到它，由於這個測試也會失敗。當測試經過時，什麼也不該當打印出來。在編寫測試代碼時，使用print語句有時是有用的。可是在須要用print的地方應當設置一個標誌位，用來在進行測試的時候屏蔽它。

5. 查看日誌信息，而不是運行結果。 還好這並不廣泛，可是我卻見過一個很是有能力的開發人員這麼幹過。要知道，真正重要的是方法的運行結果，而不是日誌中都打印了什麼，由於即便代碼中有錯誤，測試也可能會經過。好了，說的很明白了。

後面3個問題都很容易規避。頭2個問題則須要付出更多努力，可是會獲得良好分離的代碼。