談談爲何寫單元測試

原文：http://www.jianshu.com/p/bc99678b1d6e
做者：鍵盤男kkmike999

單元測試是什麼

單元測試 是針對 程序的最小單元 來進行正確性檢驗的測試工做。程序單元是應用的最小可測試部件。一個單元多是單個程序、類、對象、方法等。 ——維基百科

---

項目存在問題

2016年以前，我司的Android項目都是用肉眼review + 真機測試作功能測試，對junit、robolectric、espresso望而生畏。其緣由是：

• 缺少unit test意識 & 實踐經驗

• 框架對單元測試不友好

• 業務繁重

• 研發人手不足

當時工程面臨問題：

• 代碼耦合度較高

• 架構落後

• 各類bug

因爲缺少單元測試認識、實踐，致使對框架重構迷失目標。意識不足是很嚴重的問題，框架重構沒有方向。所以，首要任務，就是對單元測試全面瞭解。

---

單元測試意義

• 減小bug

• 快速定位bug

• 提升代碼質量

• 減小調試時間
  ...

減小bug

一個機器，由各類細小的零件組成，若是其中某件零件壞了，機器運行故障。必須保證每一個零件都按設計圖要求的規格，機器才能正常運行。

一個可單元測試的工程，會把業務、功能分割成規模更小、有獨立的邏輯部件，稱爲單元。單元測試的目標，就是保證各個單元的邏輯正確性。單元測試保障工程各個「零件」按「規格」（需求）執行，從而保證整個「機器」（項目）運行正確，最大限度減小bug。

提升代碼質量

因爲每一個單元有獨立的邏輯，作單元測試時須要隔離外部依賴，確保這些依賴不影響驗證邏輯。由於要把各類依賴分離，單元測試會促進工程進行組件拆分，整理工程依賴關係，更大程度減小代碼耦合。這樣寫出來的代碼，更好維護，更好擴展，從而提升代碼質量。

快速定位bug、減小調試時間

若是程序有bug，咱們運行一次所有單元測試，找到不經過的測試，能夠很快地定位對應的執行代碼。修復代碼後，運行對應的單元測試；如還不經過，繼續修改，運行測試.....直到測試經過。

對於Android項目，要測試某個功能點，不用單元測試的話，必須運行在真機、模擬器上，慢慢debug找到問題點。運行程序到真機，快則半分鐘，慢則幾分鐘。junit只需在本地運行便可，就幾秒的事（robolectric須要十幾秒）。有時，寫那個功能模塊的員工已離職，APP運行出錯（邏輯錯誤，非crash or exception），你根本就不知道調試哪一個類。若是離職的員工以前寫了單元測試，運行一下立馬就找到問題點了。單元測試大大減小調試時間，從而達到節約時間成本的效果。

放心重構

重構，每一個開發者都會經歷，重構後把代碼改壞了的狀況並很多見。以往，寫完一個框架，運行APP，沒什麼問題，完事。因爲最初的框架並非你寫的，可謂牽一髮動全身，你改1個方法致使整個框架運行失敗....

若是你有單元測試，狀況大不相同。寫完一個類，把單元測試寫了，確保這個類邏輯正確；寫第二個類，單元測試.....寫100個類，道理同樣，每一個類作到第一點「保證邏輯正確性」，100個類拼在一塊兒確定不出問題。你大能夠放心一邊重構，一邊運行APP；而不是總體重構完，提心跳膽地run。

---

誰逼你寫單元測試？

領導要求

有些經驗豐富的領導，或多或少都會要求團隊寫單元測試。對於有必定工做經驗的隊友，這要求挺合理；對於經驗尚淺的、畢業生，恐怕要死要活了，連代碼都寫很差，還要寫單元測試，are you kidding me？

培訓新人單元測試用法，是一項艱鉅的任務。新人代碼風格未造成，也不知道單元測試多重要，強制單元測試會讓他們感到困惑，沒辦法按本身思路寫代碼。

大牛都寫單元測試

國外不少家喻戶曉的開源項目，都有大量單元測試。例如，retrofit、okhttp、butterknife.... 國外大牛都寫單元測試，咱們也寫吧！

不少讀者都有這種想法，一開始滿腔熱血。當真要對本身項目單元測試時，便困難重重，很大緣由是項目對單元測試不友好。最後只能對一些不痛不癢的工具類作單元測試，長此以往，當初美好願望也不了了之。

保住面子

都是有些許年經驗的老鳥，還每天被測試同窗追bug，好意思麼？花多一點時間寫單元測試，確保沒低級bug，還能彰顯大牛風範，何樂而不爲？

心虛

筆者也是個不太相信本身代碼的人，總以爲哪裏會忽然冒出莫名其妙的bug，也怕別人不當心改了本身的代碼（被害妄想症），新版本上線提心跳膽......花點時間寫單元測試，有事沒事跑一下測試，確保原邏輯沒問題，至少能睡安穩一點。

---

TDD 測試驅動開發

Test-Driven Development, 測試驅動開發， 是敏捷開發的一項核心實踐和技術，也是一種設計方法論。TDD原理是開發功能代碼以前，先編寫測試用例代碼，而後針對測試用例編寫功能代碼，使其可以經過。因爲TDD對開發人員要求很是高，跟傳統開發思惟不同，所以實施起來至關困難。

測試驅動開發有好處也有壞處。由於每一個測試用例都是根據需求來的，或者說把一個大需求分解成若干小需求編寫測試用例，因此測試用例寫出來後，開發者寫的執行代碼，必須知足測試用例。若是測試不經過，則修改執行代碼，直到測試用例經過。

好處，經過測試的執行代碼，確定知足需求，並且有助於接口編程，下降代碼耦合，也極大下降bug出現概率（若是是極限編程，幾乎是不可能有bug）。壞處，1.投入開發資源（時間和精力）；2.因爲測試用例在未進行代碼設計前寫；頗有可能限制開發者對代碼總體設計；3.可能引發開發人員不滿情緒，我以爲這點很嚴重，畢竟不是人人都喜歡單元測試，儘管單元測試會帶給咱們至關多的好處。

---

總結

單元測試確實會帶給你至關多的好處，但不是馬上體驗出來。正如買重疾保險，交了不少保費，沒病沒痛，十幾年甚至幾十年都用不上，最好就是一生用不上理賠，身體健康最重要。單元測試也同樣，寫了能夠買個放心，對代碼的一種保障，有bug儘快測出來，沒bug就最好，總不能說「寫那麼多單元測試，結果測不出bug，浪費時間」吧？

如下是我的對單元測試一些建議：

• 越重要的代碼，越要寫單元測試；

• 代碼作不到單元測試，多思考如何改進，而不是放棄；

• 邊寫業務代碼，邊寫單元測試，而不是完成整個新功能後再寫；

• 多思考如何改進、簡化測試代碼。

做爲一名經驗豐富的程序員，寫單元測試更多的是對本身的代碼負責。有測試用例的代碼，別人更容易看懂，之後別人接手你的代碼時，也可能放心作改動。

多敲代碼實踐，多跟有單元測試經驗的工程師交流，你會發現寫單元測試得到的收益會更多。

---

關於做者

我是鍵盤男。在廣州生活，在創業公司上班，猥瑣僞文藝青年。喜歡科學、歷史，玩玩投資，偶爾獨自旅行。但願成爲獨當一面的工程師。