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

單元測試(基礎篇)

一、什么是UT

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

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

二、UT的任務

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

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

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

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

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

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

4.    建立程序員的自信

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

三、UT的基本原則

1.一個類、一個方法、一條路徑

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

原因在于：

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

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

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

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

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

3.保證測試方法簡潔

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

四、如何才能做UT

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

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

其次是，低Ce和單一責任原則。一個方法對外的依賴應該單一，不應該取決于很多的外部環(huán)境。因為不同的外部環(huán)境越多，組合項就越多，要測的先決條件就越多。而一個方法對外部環(huán)境的影響太多，則意味著職責不單一，對于輸出越難測。

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

2.信任你該信任的。

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

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

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

另一方面，單元測試必須自動化 ，必須簡單，傻瓜化。這是我們要努力的目標。

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

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

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

難以打樁。因為我們對其它模塊的關聯(lián)是這樣的。

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

1.    望而生畏，太多。

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

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

因為，我希望的是這樣的：

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

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