單元測試目的：
首先保證代碼質量。
其次保證代碼的可維護。
再此保證代碼的可擴展。
目的之一代碼的代碼質量。
我們編寫的代碼雖然可以通過編譯器檢測到語法的正確性質，但并不能保證代碼邏輯也是正確的。我們該怎么保證代碼執行是正確的呢。好下面我們來看下代碼。
java 代碼
int add(int x, int y){
return x+y;
}
上面的功能模塊。下面是段測試代碼
java 代碼
void testAdd(){
//我們要求程序邏輯是1＋4＝5；
assertEquals(5,add(1,4);
}
經過測試以后，如果你修改了int add(int x, int y);里面的邏輯，如果修改的正確，測試代碼始終都是見到綠色的。如果你邏輯錯了。那不好意思，你的測試將會讓你重新寫那段邏輯代碼。直到你正確為止。
有個比較特殊的情況，如果我測試代碼寫成這樣，那我保證邏輯代碼的正確性，但我卻看不到我期待的綠色，這有是什么原因呢？
java 代碼
1. void testAdd(){
2. //我們要求程序邏輯是1＋4＝5；
3. assertEquals(6,add(1,4);
4. }
我個人認為這個問題并是邏輯代碼的問題，而是你測試代碼中的邏輯問題，
噢，MyGot，作為程序員的我。已經為邏輯代碼傷腦筋了。還要為測試代碼煩惱，做人真命苦啊。 想來也確實是這樣。
這就引申了另外一個問題，怎么樣才可以保證我邏輯代碼的可測性?
目的之二代碼的可維護性。
就拿上面的例子來說吧。只要我們的單元測試是正確的，那我們就可以保證無論你怎么修改那段代碼，只要測試代碼可以產生綠色條，那OK，你修改的邏輯代碼是正確的。當然可維護并非只有這點，還有，比如保證修改了這段代碼不會影響到其他的模塊等。
目的之三代碼的可擴展。
對于這點我理解很膚淺。只能表達表面的東西，希望。
對于可擴展我覺得保遵循一個代碼之間的耦合度降到最低。就OK了。單元測試對這方面有很強的好處，為了程序的可維護性，它可以強迫你寫低耦合度的程序。
單元測試的優點
1、它是一種驗證行為。
程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發提供支緩。就算是開發后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。
2、它是一種設計行為。
編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試（test-first），迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。
3、它是一種編寫文檔的行為。
單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。
4、它具有回歸性。
自動化的單元測試避免了代碼出現回歸，編寫完成之后，可以隨時隨地的快速運行測試。
單元測試的范疇
如果要給單元測試定義一個明確的范疇，指出哪些功能是屬于單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的范疇，單元測試所要做的工作。
1、 它的行為和我期望的一致嗎？
這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。
2、 它的行為一直和我期望的一致嗎？
編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一 致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致；譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。
3、 我可以依賴單元測試嗎？
不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。
4、 單元測試說明我的意圖了嗎？
單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/