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

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

一、什么是UT

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

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

二、UT的任務(wù)

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

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

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

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

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

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

4.    建立程序員的自信

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

三、UT的基本原則

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

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

原因在于：

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

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

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

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

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

3.保證測試方法簡潔

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

四、如何才能做UT

1.代碼要首先可測，然后才能測。

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

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

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

2.信任你該信任的。

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

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

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

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

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

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

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

難以打樁。因?yàn)槲覀儗ζ渌K的關(guān)聯(lián)是這樣的。

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

1.    望而生畏，太多。

2.    無法下手，都是直接對象依賴，而不是接口依賴。

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

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

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

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