這篇文章的主旨是在正式進(jìn)行單元測(cè)試之前幫助大家厘清一些概念。了解什么是單元測(cè)試，可以做什么，有哪些指導(dǎo)原則。做了又有什么好處，它又存在什么樣的局限性。最后重點(diǎn)講了現(xiàn)在做單元測(cè)試的難點(diǎn)。事實(shí)上這是任何單元測(cè)試都會(huì)面臨的一個(gè)問題。在這里分享我的觀點(diǎn)，與大家共勉！

單元測(cè)試(基礎(chǔ)篇)

一、什么是UT

UT測(cè)的是方法，檢驗(yàn)的是一個(gè)類對(duì)外界的承諾。因此，大多數(shù)情況下，我們測(cè)的應(yīng)該是公共方法，除非不得已才對(duì)私有方法進(jìn)行測(cè)試。

方法是程序設(shè)計(jì)的最小單位。UT的局限也體現(xiàn)在這里，它并沒有針對(duì)類之間的交互做檢驗(yàn)。所以，不能指望單元測(cè)試做完了，就沒有問題了。在這個(gè)方面的欠缺，我們可以通過(guò)自動(dòng)化的功能/組件測(cè)試來(lái)完成。這也是開發(fā)者測(cè)試的一部分。

二、UT的任務(wù)

1.    盡早的發(fā)現(xiàn)問題

說(shuō)白了，就是不要讓問題流出去。讓我們的缺陷率降低，把我們的產(chǎn)品做的漂亮。另一方面，一些細(xì)類度的問題在這里也確實(shí)更容易發(fā)現(xiàn)，同時(shí)也為進(jìn)行更大粒度的測(cè)試做好集成準(zhǔn)備。

2.    編織一層保護(hù)網(wǎng)

給新的代碼建立有效的保護(hù)。 保證對(duì)代碼每一份改動(dòng)，都不會(huì)對(duì)現(xiàn)有系統(tǒng)造成傷害。避免了引入問題。

3.寫出優(yōu)雅的代碼

編寫單元測(cè)試的過(guò)程，實(shí)質(zhì)是使用我們自己代碼的過(guò)程。我們成了第一個(gè)真正意義上的體驗(yàn)者。在這個(gè)過(guò)程中，我們?yōu)榱耸勾a易用會(huì)進(jìn)行不斷的重構(gòu)。最終的交付代碼必然會(huì)更優(yōu)雅。

4.    建立程序員的自信

我們習(xí)慣于兩眼一抹黑，不管三七二十一就把代碼寫完了。Code階段結(jié)束，然后不斷的調(diào)試，修修補(bǔ)補(bǔ)跑起來(lái)就過(guò)了TR4。沒人敢說(shuō)，他代碼一寫完了，就能跑起來(lái)。這種做法是很沒人性的，系統(tǒng)搞掛幾次后就心里發(fā)虛，一點(diǎn)底氣都沒有。但是，這是我們的職業(yè)，我們?yōu)橹约旱臉s耀而戰(zhàn)。在任何時(shí)候，都需要信心滿盈。

三、UT的基本原則

1.一個(gè)類、一個(gè)方法、一條路徑

我們一次只測(cè)一個(gè)類的一個(gè)方法。剛開始做單元測(cè)試的時(shí)候，很多人會(huì)自然而然的做成了功能測(cè)試。因?yàn)椋耙徊糠謭?zhí)行的結(jié)果恰好為后一部分準(zhǔn)備好了輸入。而另一方面，連續(xù)的執(zhí)行過(guò)程組成了一個(gè)明確的場(chǎng)景，讓具體的功能變得完整可見，這正是我們期待的，讓我們變得有信心。那為什么不順其自然呢？

原因在于：

1）、單元測(cè)試要保證一定的微粒度。從單元測(cè)試到功能測(cè)試，這之間的粒度會(huì)越來(lái)越大，越往后，我們會(huì)越少的關(guān)注細(xì)節(jié)。如果直接跳躍到功能測(cè)試上，會(huì)讓我們遺漏掉一些問題，在以后的粗粒度測(cè)試中，它們會(huì)轉(zhuǎn)變?yōu)楹茈y重現(xiàn)或者不可重現(xiàn)的致命問題。

2）、上述場(chǎng)景之所以會(huì)出現(xiàn)，是因?yàn)橄葘懘a后寫測(cè)試導(dǎo)致的。相當(dāng)于代碼已經(jīng)集成，具備了做功能測(cè)試的一定條件。這個(gè)時(shí)候讓再走回頭路做單元測(cè)試，當(dāng)然不如直接就做功能測(cè)試來(lái)的順當(dāng)。所以，應(yīng)該一個(gè)測(cè)試、一個(gè)方法，一個(gè)方法一個(gè)測(cè)試，這樣不斷的一步一步的循環(huán)迭代集成來(lái)的好。

另一方面，為了將一個(gè)方法的多個(gè)不同的執(zhí)行路徑分開，我們必須保證一次只測(cè)一個(gè)方法的一個(gè)路徑。這樣，前置條件和后置條件就會(huì)很明確，容易準(zhǔn)備測(cè)試環(huán)境。

2.重構(gòu)以便于測(cè)試

面對(duì)著一個(gè)方法，你感到一籌莫展。并不是你的錯(cuò)，而是因?yàn)檫@個(gè)方法很爛。測(cè)一個(gè)方法就是在使用這個(gè)方法，你自己都這樣無(wú)奈，將來(lái)真正使用的人豈不是要罵娘？雁過(guò)留聲，人過(guò)留名。這個(gè)時(shí)候，重構(gòu)一下很值得。

3.保證測(cè)試方法簡(jiǎn)潔

如果連測(cè)試方法都很復(fù)雜，難道我們還要再寫測(cè)試用例來(lái)保證它的正確執(zhí)行不成？這樣豈不是麻煩大了！所以，測(cè)試方法一定要寫的盡可能的簡(jiǎn)單，寫到你認(rèn)為白癡都能看懂的程度。

四、如何才能做UT

1.代碼要首先可測(cè)，然后才能測(cè)。

首先要遵守契約式設(shè)計(jì)。類的每一個(gè)方法都應(yīng)該對(duì)外承擔(dān)了一份契約，有明確的前置條件和后置條件。 當(dāng)你對(duì)這個(gè)方法進(jìn)行測(cè)試之前必須清楚明白這兩個(gè)條件。一個(gè)有效的方法一定是做了什么事的。一定會(huì)產(chǎn)生一定的影響，我們可以通過(guò)對(duì)外圍環(huán)境的改變來(lái)檢測(cè)方法產(chǎn)生的作用是否如預(yù)期(例如,獲取某一對(duì)象的屬性進(jìn)行檢測(cè))。

其次是，低Ce和單一責(zé)任原則。一個(gè)方法對(duì)外的依賴應(yīng)該單一，不應(yīng)該取決于很多的外部環(huán)境。因?yàn)椴煌耐獠凯h(huán)境越多，組合項(xiàng)就越多，要測(cè)的先決條件就越多。而一個(gè)方法對(duì)外部環(huán)境的影響太多，則意味著職責(zé)不單一，對(duì)于輸出越難測(cè)。

曾經(jīng)聽有人講到，這些道理，你懂了就懂，不懂就不懂，說(shuō)了沒用。但我認(rèn)為，如果你還以為這些只是大道理，如果你還想對(duì)它有點(diǎn)切身的感受，做單元測(cè)試是一個(gè)很好的途徑。

2.信任你該信任的。

對(duì)于已經(jīng)穩(wěn)定的部分，類似于第三方包，平臺(tái)部分，其至是遺留系統(tǒng)中已經(jīng)證明是可靠的部分，都可以信任。這些是我們用例代碼依賴的部分，是我們用來(lái)檢驗(yàn)其它待測(cè)部分的基石。如果什么都要測(cè)，就會(huì)變成什么都測(cè)不了。

3.    單元測(cè)試要盡量少的增加開發(fā)人員的負(fù)擔(dān)。

一方面，我們實(shí)在被問題單壓抑的太久了。所以，從全局上來(lái)看待這個(gè)問題，如果可以確實(shí)的減少后期的維護(hù)壓力，對(duì)我們自身而言當(dāng)然是有益的。所謂增加的負(fù)擔(dān)，不過(guò)是提早了結(jié)了一些痛苦。

另一方面，單元測(cè)試必須自動(dòng)化 ，必須簡(jiǎn)單，傻瓜化。這是我們要努力的目標(biāo)。

4.將調(diào)試的時(shí)間用來(lái)寫單元測(cè)試

沒有做過(guò)自動(dòng)化單元測(cè)試的人永遠(yuǎn)也不能體會(huì)其給程序員帶來(lái)的自信和好處。如果你還在調(diào)試，不如順手加個(gè)測(cè)試。以后，保證同樣的問題不會(huì)從你的眼皮下溜走。

5.    現(xiàn)在的單元測(cè)試難在哪里？

難以打樁。因?yàn)槲覀儗?duì)其它模塊的關(guān)聯(lián)是這樣的。

這就是麻煩的所在，關(guān)聯(lián)太多。如果我們要測(cè)，我們就要打樁。但是，

1.    望而生畏，太多。

2.    無(wú)法下手，都是直接對(duì)象依賴，而不是接口依賴。

所以，你讓我來(lái)測(cè)這樣的代碼，我是不會(huì)干的。

因?yàn)椋蚁Ｍ氖沁@樣的：

但是，我們現(xiàn)在的代碼欠債太多了。沒有條件和能力再回去對(duì)這些代碼進(jìn)行單元測(cè)試。而且，這些功能經(jīng)過(guò)這么多年的維護(hù)，大多已穩(wěn)定。做的性價(jià)比也不高,不夠?qū)嵒荨Ｋ裕槐匾觥?/span>

但在新功能開發(fā)過(guò)程中，這些老代碼依舊會(huì)如惡夢(mèng)一樣糾纏著我們。讓寫單元測(cè)試過(guò)程中常常面臨著舉步維艱的境地。我們不得不在讓代碼變得可測(cè)與對(duì)代碼的侵入性測(cè)試之間進(jìn)行抉擇。