摘要：原文作者鍵盤男單元測(cè)試是什么單元測(cè)試是針對(duì)程序的最小單元來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作。因此，首要任務(wù)，就是對(duì)單元測(cè)試全面了解。作為一名經(jīng)驗(yàn)豐富的程序員，寫單元測(cè)試更多的是對(duì)自己的代碼負(fù)責(zé)。

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

單元測(cè)試 是針對(duì) 程序的最小單元 來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作。程序單元是應(yīng)用的最小可測(cè)試部件。一個(gè)單元可能是單個(gè)程序、類、對(duì)象、方法等。    ——維基百科

2016年之前，我司的Android項(xiàng)目都是用肉眼review + 真機(jī)測(cè)試做功能測(cè)試，對(duì)junit、robolectric、espresso望而生畏。其原因是：

缺乏unit test意識(shí) & 實(shí)踐經(jīng)驗(yàn)

框架對(duì)單元測(cè)試不友好

業(yè)務(wù)繁重

研發(fā)人手不足

當(dāng)時(shí)工程面臨問(wèn)題：

代碼耦合度較高

架構(gòu)落后

各種bug

由于缺乏單元測(cè)試認(rèn)識(shí)、實(shí)踐，導(dǎo)致對(duì)框架重構(gòu)迷失目標(biāo)。意識(shí)不足是很嚴(yán)重的問(wèn)題，框架重構(gòu)沒(méi)有方向。因此，首要任務(wù)，就是對(duì)單元測(cè)試全面了解。

減少bug

快速定位bug

提高代碼質(zhì)量

減少調(diào)試時(shí)間
...

一個(gè)機(jī)器，由各種細(xì)小的零件組成，如果其中某件零件壞了，機(jī)器運(yùn)行故障。必須保證每個(gè)零件都按設(shè)計(jì)圖要求的規(guī)格，機(jī)器才能正常運(yùn)行。

一個(gè)可單元測(cè)試的工程，會(huì)把業(yè)務(wù)、功能分割成規(guī)模更小、有獨(dú)立的邏輯部件，稱為單元。單元測(cè)試的目標(biāo)，就是保證各個(gè)單元的邏輯正確性。單元測(cè)試保障工程各個(gè)“零件”按“規(guī)格”（需求）執(zhí)行，從而保證整個(gè)“機(jī)器”（項(xiàng)目）運(yùn)行正確，最大限度減少bug。

由于每個(gè)單元有獨(dú)立的邏輯，做單元測(cè)試時(shí)需要隔離外部依賴，確保這些依賴不影響驗(yàn)證邏輯。因?yàn)橐迅鞣N依賴分離，單元測(cè)試會(huì)促進(jìn)工程進(jìn)行組件拆分，整理工程依賴關(guān)系，更大程度減少代碼耦合。這樣寫出來(lái)的代碼，更好維護(hù)，更好擴(kuò)展，從而提高代碼質(zhì)量。

如果程序有bug，我們運(yùn)行一次全部單元測(cè)試，找到不通過(guò)的測(cè)試，可以很快地定位對(duì)應(yīng)的執(zhí)行代碼。修復(fù)代碼后，運(yùn)行對(duì)應(yīng)的單元測(cè)試；如還不通過(guò)，繼續(xù)修改，運(yùn)行測(cè)試.....直到測(cè)試通過(guò)。

對(duì)于Android項(xiàng)目，要測(cè)試某個(gè)功能點(diǎn)，不用單元測(cè)試的話，必須運(yùn)行在真機(jī)、模擬器上，慢慢debug找到問(wèn)題點(diǎn)。運(yùn)行程序到真機(jī)，快則半分鐘，慢則幾分鐘。junit只需在本地運(yùn)行即可，就幾秒的事（robolectric需要十幾秒）。有時(shí)，寫那個(gè)功能模塊的員工已離職，APP運(yùn)行出錯(cuò)（邏輯錯(cuò)誤，非crash or exception），你根本就不知道調(diào)試哪個(gè)類。如果離職的員工之前寫了單元測(cè)試，運(yùn)行一下立馬就找到問(wèn)題點(diǎn)了。單元測(cè)試大大減少調(diào)試時(shí)間，從而達(dá)到節(jié)約時(shí)間成本的效果。

重構(gòu)，每個(gè)開(kāi)發(fā)者都會(huì)經(jīng)歷，重構(gòu)后把代碼改壞了的情況并不少見(jiàn)。以往，寫完一個(gè)框架，運(yùn)行APP，沒(méi)什么問(wèn)題，完事。由于最初的框架并不是你寫的，可謂牽一發(fā)動(dòng)全身，你改1個(gè)方法導(dǎo)致整個(gè)框架運(yùn)行失敗....

如果你有單元測(cè)試，情況大不相同。寫完一個(gè)類，把單元測(cè)試寫了，確保這個(gè)類邏輯正確；寫第二個(gè)類，單元測(cè)試.....寫100個(gè)類，道理一樣，每個(gè)類做到第一點(diǎn)“保證邏輯正確性”，100個(gè)類拼在一起肯定不出問(wèn)題。你大可以放心一邊重構(gòu)，一邊運(yùn)行APP；而不是整體重構(gòu)完，提心跳膽地run。

有些經(jīng)驗(yàn)豐富的領(lǐng)導(dǎo)，或多或少都會(huì)要求團(tuán)隊(duì)寫單元測(cè)試。對(duì)于有一定工作經(jīng)驗(yàn)的隊(duì)友，這要求挺合理；對(duì)于經(jīng)驗(yàn)尚淺的、畢業(yè)生，恐怕要死要活了，連代碼都寫不好，還要寫單元測(cè)試，are you kidding me？

培訓(xùn)新人單元測(cè)試用法，是一項(xiàng)艱巨的任務(wù)。新人代碼風(fēng)格未形成，也不知道單元測(cè)試多重要，強(qiáng)制單元測(cè)試會(huì)讓他們感到困惑，沒(méi)辦法按自己思路寫代碼。

國(guó)外很多家喻戶曉的開(kāi)源項(xiàng)目，都有大量單元測(cè)試。例如，retrofit、okhttp、butterknife.... 國(guó)外大牛都寫單元測(cè)試，我們也寫吧！

很多讀者都有這種想法，一開(kāi)始滿腔熱血。當(dāng)真要對(duì)自己項(xiàng)目單元測(cè)試時(shí)，便困難重重，很大原因是項(xiàng)目對(duì)單元測(cè)試不友好。最后只能對(duì)一些不痛不癢的工具類做單元測(cè)試，久而久之，當(dāng)初美好愿望也不了了之。

都是有些許年經(jīng)驗(yàn)的老鳥(niǎo)，還天天被測(cè)試同學(xué)追bug，好意思么？花多一點(diǎn)時(shí)間寫單元測(cè)試，確保沒(méi)低級(jí)bug，還能彰顯大牛風(fēng)范，何樂(lè)而不為？

筆者也是個(gè)不太相信自己代碼的人，總覺(jué)得哪里會(huì)突然冒出莫名其妙的bug，也怕別人不小心改了自己的代碼（被害妄想癥），新版本上線提心跳膽......花點(diǎn)時(shí)間寫單元測(cè)試，有事沒(méi)事跑一下測(cè)試，確保原邏輯沒(méi)問(wèn)題，至少能睡安穩(wěn)一點(diǎn)。

Test-Driven Development, 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)， 是敏捷開(kāi)發(fā)的一項(xiàng)核心實(shí)踐和技術(shù)，也是一種設(shè)計(jì)方法論。TDD原理是開(kāi)發(fā)功能代碼之前，先編寫測(cè)試用例代碼，然后針對(duì)測(cè)試用例編寫功能代碼，使其能夠通過(guò)。由于TDD對(duì)開(kāi)發(fā)人員要求非常高，跟傳統(tǒng)開(kāi)發(fā)思維不一樣，因此實(shí)施起來(lái)相當(dāng)困難。

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)有好處也有壞處。因?yàn)槊總€(gè)測(cè)試用例都是根據(jù)需求來(lái)的，或者說(shuō)把一個(gè)大需求分解成若干小需求編寫測(cè)試用例，所以測(cè)試用例寫出來(lái)后，開(kāi)發(fā)者寫的執(zhí)行代碼，必須滿足測(cè)試用例。如果測(cè)試不通過(guò)，則修改執(zhí)行代碼，直到測(cè)試用例通過(guò)。

好處，通過(guò)測(cè)試的執(zhí)行代碼，肯定滿足需求，而且有助于接口編程，降低代碼耦合，也極大降低bug出現(xiàn)幾率（如果是極限編程，幾乎是不可能有bug）。壞處，1.投入開(kāi)發(fā)資源（時(shí)間和精力）；2.由于測(cè)試用例在未進(jìn)行代碼設(shè)計(jì)前寫；很有可能限制開(kāi)發(fā)者對(duì)代碼整體設(shè)計(jì)；3.可能引起開(kāi)發(fā)人員不滿情緒，我覺(jué)得這點(diǎn)很嚴(yán)重，畢竟不是人人都喜歡單元測(cè)試，盡管單元測(cè)試會(huì)帶給我們相當(dāng)多的好處。

單元測(cè)試確實(shí)會(huì)帶給你相當(dāng)多的好處，但不是立刻體驗(yàn)出來(lái)。正如買重疾保險(xiǎn)，交了很多保費(fèi)，沒(méi)病沒(méi)痛，十幾年甚至幾十年都用不上，最好就是一輩子用不上理賠，身體健康最重要。單元測(cè)試也一樣，寫了可以買個(gè)放心，對(duì)代碼的一種保障，有bug盡快測(cè)出來(lái)，沒(méi)bug就最好，總不能說(shuō)“寫那么多單元測(cè)試，結(jié)果測(cè)不出bug，浪費(fèi)時(shí)間”吧？

以下是個(gè)人對(duì)單元測(cè)試一些建議：

越重要的代碼，越要寫單元測(cè)試；

代碼做不到單元測(cè)試，多思考如何改進(jìn)，而不是放棄；

邊寫業(yè)務(wù)代碼，邊寫單元測(cè)試，而不是完成整個(gè)新功能后再寫；

多思考如何改進(jìn)、簡(jiǎn)化測(cè)試代碼。

作為一名經(jīng)驗(yàn)豐富的程序員，寫單元測(cè)試更多的是對(duì)自己的代碼負(fù)責(zé)。有測(cè)試用例的代碼，別人更容易看懂，以后別人接手你的代碼時(shí)，也可能放心做改動(dòng)。

多敲代碼實(shí)踐，多跟有單元測(cè)試經(jīng)驗(yàn)的工程師交流，你會(huì)發(fā)現(xiàn)寫單元測(cè)試獲得的收益會(huì)更多。

關(guān)于作者

我是鍵盤男。
在廣州生活，在創(chuàng)業(yè)公司上班，猥瑣偽文藝青年。喜歡科學(xué)、歷史，玩玩投資，偶爾獨(dú)自旅行。希望成為獨(dú)當(dāng)一面的工程師。