單元測試是什么

單元測試 是針對 程序的最小單元 來進行正確性檢驗的測試工作账蓉。程序單元是應(yīng)用的最小可測試部件粒没。一個單元可能是單個程序筛婉、類、對象癞松、方法等爽撒。 ——維基百科

項目存在問題

2016年之前，我司的Android項目都是用肉眼review + 真機測試做功能測試响蓉，對junit硕勿、robolectric、espresso望而生畏枫甲。其原因是：

• 缺乏unit test意識 & 實踐經(jīng)驗
• 框架對單元測試不友好
• 業(yè)務(wù)繁重
• 研發(fā)人手不足

當時工程面臨問題：

• 代碼耦合度較高
• 架構(gòu)落后
• 各種bug

由于缺乏單元測試認識源武、實踐扼褪，導(dǎo)致對框架重構(gòu)迷失目標。意識不足是很嚴重的問題粱栖，框架重構(gòu)沒有方向话浇。因此，首要任務(wù)闹究，就是對單元測試全面了解幔崖。

單元測試意義

• 減少bug
• 快速定位bug
• 提高代碼質(zhì)量
• 減少調(diào)試時間
  ...

減少bug

一個機器，由各種細小的零件組成渣淤，如果其中某件零件壞了赏寇，機器運行故障。必須保證每個零件都按設(shè)計圖要求的規(guī)格价认，機器才能正常運行嗅定。

一個可單元測試的工程，會把業(yè)務(wù)用踩、功能分割成規(guī)模更小渠退、有獨立的邏輯部件，稱為單元脐彩。單元測試的目標智什，就是保證各個單元的邏輯正確性。單元測試保障工程各個“零件”按“規(guī)格”（需求）執(zhí)行丁屎，從而保證整個“機器”（項目）運行正確，最大限度減少bug旱眯。

提高代碼質(zhì)量

由于每個單元有獨立的邏輯晨川，做單元測試時需要隔離外部依賴，確保這些依賴不影響驗證邏輯删豺。因為要把各種依賴分離共虑，單元測試會促進工程進行組件拆分，整理工程依賴關(guān)系呀页，更大程度減少代碼耦合妈拌。這樣寫出來的代碼，更好維護蓬蝶，更好擴展尘分，從而提高代碼質(zhì)量。

快速定位bug丸氛、減少調(diào)試時間

如果程序有bug培愁，我們運行一次全部單元測試，找到不通過的測試缓窜，可以很快地定位對應(yīng)的執(zhí)行代碼定续。修復(fù)代碼后谍咆，運行對應(yīng)的單元測試；如還不通過私股，繼續(xù)修改摹察，運行測試.....直到測試通過。

對于Android項目倡鲸，要測試某個功能點供嚎，不用單元測試的話，必須運行在真機旦签、模擬器上查坪，慢慢debug找到問題點。運行程序到真機宁炫，快則半分鐘偿曙，慢則幾分鐘。junit只需在本地運行即可羔巢，就幾秒的事（robolectric需要十幾秒）望忆。有時，寫那個功能模塊的員工已離職竿秆，APP運行出錯（邏輯錯誤启摄，非crash or exception），你根本就不知道調(diào)試哪個類幽钢。如果離職的員工之前寫了單元測試歉备，運行一下立馬就找到問題點了。單元測試大大減少調(diào)試時間匪燕，從而達到節(jié)約時間成本的效果蕾羊。

放心重構(gòu)

重構(gòu)，每個開發(fā)者都會經(jīng)歷帽驯，重構(gòu)后把代碼改壞了的情況并不少見龟再。以往，寫完一個框架尼变，運行APP利凑，沒什么問題抓半，完事崇裁。由于最初的框架并不是你寫的，可謂牽一發(fā)動全身碍庵，你改1個方法導(dǎo)致整個框架運行失敗....

如果你有單元測試蛉威，情況大不相同日丹。寫完一個類，把單元測試寫了蚯嫌，確保這個類邏輯正確哲虾；寫第二個類丙躏，單元測試.....寫100個類，道理一樣束凑，每個類做到第一點“保證邏輯正確性”晒旅，100個類拼在一起肯定不出問題。你大可以放心一邊重構(gòu)汪诉，一邊運行APP废恋；而不是整體重構(gòu)完，提心跳膽地run扒寄。

誰逼你寫單元測試鱼鼓？

領(lǐng)導(dǎo)要求

有些經(jīng)驗豐富的領(lǐng)導(dǎo)，或多或少都會要求團隊寫單元測試该编。對于有一定工作經(jīng)驗的隊友迄本，這要求挺合理；對于經(jīng)驗尚淺的课竣、畢業(yè)生嘉赎，恐怕要死要活了，連代碼都寫不好于樟，還要寫單元測試公条，are you kidding me？

培訓(xùn)新人單元測試用法迂曲，是一項艱巨的任務(wù)靶橱。新人代碼風格未形成，也不知道單元測試多重要路捧，強制單元測試會讓他們感到困惑抓韩，沒辦法按自己思路寫代碼。

大牛都寫單元測試

國外很多家喻戶曉的開源項目鬓长，都有大量單元測試。例如尝江，retrofit涉波、okhttp、butterknife.... 國外大牛都寫單元測試炭序，我們也寫吧啤覆！

很多讀者都有這種想法，一開始滿腔熱血惭聂。當真要對自己項目單元測試時窗声，便困難重重，很大原因是項目對單元測試不友好辜纲。最后只能對一些不痛不癢的工具類做單元測試笨觅，久而久之拦耐，當初美好愿望也不了了之。

保住面子

都是有些許年經(jīng)驗的老鳥见剩，還天天被測試同學(xué)追bug杀糯，好意思么？花多一點時間寫單元測試苍苞，確保沒低級bug固翰，還能彰顯大牛風范，何樂而不為羹呵？

心虛

筆者也是個不太相信自己代碼的人骂际，總覺得哪里會突然冒出莫名其妙的bug，也怕別人不小心改了自己的代碼（被害妄想癥）冈欢，新版本上線提心跳膽......花點時間寫單元測試歉铝，有事沒事跑一下測試，確保原邏輯沒問題涛癌，至少能睡安穩(wěn)一點犯戏。

TDD 測試驅(qū)動開發(fā)

Test-Driven Development, 測試驅(qū)動開發(fā)， 是敏捷開發(fā)的一項核心實踐和技術(shù)拳话，也是一種設(shè)計方法論先匪。TDD原理是開發(fā)功能代碼之前，先編寫測試用例代碼弃衍，然后針對測試用例編寫功能代碼呀非，使其能夠通過。由于TDD對開發(fā)人員要求非常高镜盯，跟傳統(tǒng)開發(fā)思維不一樣岸裙，因此實施起來相當困難。

測試驅(qū)動開發(fā)有好處也有壞處速缆。因為每個測試用例都是根據(jù)需求來的降允，或者說把一個大需求分解成若干小需求編寫測試用例，所以測試用例寫出來后艺糜，開發(fā)者寫的執(zhí)行代碼剧董，必須滿足測試用例。如果測試不通過破停，則修改執(zhí)行代碼翅楼，直到測試用例通過。

好處真慢，通過測試的執(zhí)行代碼毅臊，肯定滿足需求，而且有助于接口編程黑界，降低代碼耦合管嬉，也極大降低bug出現(xiàn)幾率（如果是極限編程皂林，幾乎是不可能有bug）。壞處宠蚂，1.投入開發(fā)資源（時間和精力）式撼；2.由于測試用例在未進行代碼設(shè)計前寫；很有可能限制開發(fā)者對代碼整體設(shè)計求厕；3.可能引起開發(fā)人員不滿情緒著隆，我覺得這點很嚴重，畢竟不是人人都喜歡單元測試呀癣，盡管單元測試會帶給我們相當多的好處美浦。

總結(jié)

單元測試確實會帶給你相當多的好處，但不是立刻體驗出來项栏。正如買重疾保險浦辨，交了很多保費，沒病沒痛沼沈，十幾年甚至幾十年都用不上流酬，最好就是一輩子用不上理賠，身體健康最重要列另。單元測試也一樣芽腾，寫了可以買個放心，對代碼的一種保障页衙，有bug盡快測出來摊滔，沒bug就最好，總不能說“寫那么多單元測試店乐，結(jié)果測不出bug艰躺，浪費時間”吧？

以下是個人對單元測試一些建議：

• 越重要的代碼眨八，越要寫單元測試腺兴；
• 代碼做不到單元測試，多思考如何改進廉侧，而不是放棄含长；
• 邊寫業(yè)務(wù)代碼，邊寫單元測試伏穆，而不是完成整個新功能后再寫；
• 多思考如何改進纷纫、簡化測試代碼枕扫。

作為一名經(jīng)驗豐富的程序員，寫單元測試更多的是對自己的代碼負責辱魁。有測試用例的代碼烟瞧，別人更容易看懂诗鸭，以后別人接手你的代碼時，也可能放心做改動参滴。

多敲代碼實踐强岸，多跟有單元測試經(jīng)驗的工程師交流，你會發(fā)現(xiàn)寫單元測試獲得的收益會更多砾赔。

關(guān)于作者

我是鍵盤男蝌箍。
在廣州生活，在創(chuàng)業(yè)公司上班暴心，猥瑣文藝碼農(nóng)妓盲。喜歡科學(xué)、歷史专普，玩玩投資悯衬，偶爾獨自旅行。希望成為獨當一面的工程師檀夹。