一、什么是UT
UT測的是方法，檢驗的是一個類對外界的承諾。因此，大多數情況下，我們測的應該是公共方法，除非不得已才對私有方法進行測試。 方法是程序設計的最小單位。UT的局限也體現在這里，它并沒有針對類之間的交互做檢驗。所以，不能指望單元測試做完了，就沒有問題了。在這個方面的欠缺，我們可以通過自動化的功能/組件測試來完成。這也是開發者測試的一部分。
二、UT的任務
1. 盡早的發現問題 說白了，就是不要讓問題流出去。讓我們的缺陷率降低，把我們的產品做的漂亮。另一方面，一些細類度的問題在這里也確實更容易發現，同時也為進行更大粒度的測試做好集成準備。
2. 編織一層保護網
給新的代碼建立有效的保護。 保證對代碼每一份改動，都不會對現有系統造成傷害。避免了引入問題。
3.寫出優雅的代碼
編寫單元測試的過程，實質是使用我們自己代碼的過程。我們成了第一個真正意義上的體驗者。在這個過程中，我們為了使代碼易用會進行不斷的重構。最終的交付代碼必然會更優雅。
4. 建立程序員的自信
我們習慣于兩眼一抹黑，不管三七二十一就把代碼寫完了。Code階段結束，然后不斷的調試，修修補補跑起來就過了TR4。沒人敢說，他代碼一寫完了，就能跑起來。這種做法是很沒人性的，系統搞掛幾次后就心里發虛，一點底氣都沒有。但是，這是我們的職業，我們為著自己的榮耀而戰。在任何時候，都需要信心滿盈。
三、UT的基本原則
1.一個類、一個方法、一條路徑 我們一次只測一個類的一個方法。剛開始做單元測試的時候，很多人會自然而然的做成了功能測試。因為，前一部分執行的結果恰好為后一部分準備好了輸入。而另一方面，連續的執行過程組成了一個明確的場景，讓具體的功能變得完整可見，這正是我們期待的，讓我們變得有信心。那為什么不順其自然呢？
原因在于：
1）、單元測試要保證一定的微粒度。從單元測試到功能測試，這之間的粒度會越來越大，越往后，我們會越少的關注細節。如果直接跳躍到功能測試上，會讓我們遺漏掉一些問題，在以后的粗粒度測試中，它們會轉變為很難重現或者不可重現的致命問題。
2）、上述場景之所以會出現，是因為先寫代碼后寫測試導致的。相當于代碼已經集成，具備了做功能測試的一定條件。這個時候讓再走回頭路做單元測試，當然不如直接就做功能測試來的順當。所以，應該一個測試、一個方法，一個方法一個測試，這樣不斷的一步一步的循環迭代集成來的好。
另一方面，為了將一個方法的多個不同的執行路徑分開，我們必須保證一次只測一個方法的一個路徑。這樣，前置條件和后置條件就會很明確，容易準備測試環境。
2.重構以便于測試
面對著一個方法，你感到一籌莫展。并不是你的錯，而是因為這個方法很爛。測一個方法就是在使用這個方法，你自己都這樣無奈，將來真正使用的人豈不是要罵娘？雁過留聲，人過留名。這個時候，重構一下很值得。
3.保證測試方法簡潔
如果連測試方法都很復雜，難道我們還要再寫測試用例來保證它的正確執行不成？這樣豈不是麻煩大了！所以，測試方法一定要寫的盡可能的簡單，寫到你認為白癡都能看懂的程度。
四、如何才能做UT
1.代碼要首先可測，然后才能測。 首先要遵守契約式設計。類的每一個方法都應該對外承擔了一份契約，有明確的前置條件和后置條件。 當你對這個方法進行測試之前必須清楚明白這兩個條件。一個有效的方法一定是做了什么事的。一定會產生一定的影響，我們可以通過對外圍環境的改變來檢測方法產生的作用是否如預期(例如,獲取某一對象的屬性進行檢測)。
其次是，低Ce和單一責任原則。一個方法對外的依賴應該單一，不應該取決于很多的外部環境。因為不同的外部環境越多，組合項就越多，要測的先決條件就越多。而一個方法對外部環境的影響太多，則意味著職責不單一，對于輸出越難測。
曾經聽有人講到，這些道理，你懂了就懂，不懂就不懂，說了沒用。但我認為，如果你還以為這些只是大道理，如果你還想對它有點切身的感受，做單元測試是一個很好的途徑。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/