什么是單元測試

工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。

單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現在list 的尾部。或者，你可能會從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。

單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什么的，這，也是單元測試，把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高后期測試和維護成本，也降低了開發商的競爭力。可以說，進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。

對于程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。

要進行充分的單元測試，應專門編寫測試代碼，并與產品代碼隔離。我認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談我的看法。

一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以我的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

有一種看法是，只測試類的接口（公有函數），不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫（inline函數），所有在源文件編寫實現的函數都要進行測試（構造函數和析構函數除外）。

單元測試之測試目的

首先保證代碼質量。

其次保證代碼的可維護。

再此保證代碼的可擴展。

目的之一代碼的代碼質量。

我們編寫的代碼雖然可以通過編譯器檢測到語法的正確性質，但并不能保證代碼邏輯也是正確的。我們該怎么保證代碼執行是正確的呢。好下面我們來看下代碼。

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 代碼

void testAdd（）{

//我們要求程序邏輯是1＋4＝5；

assertEquals（6，add（1，4）;

}

我個人認為這個問題并是邏輯代碼的問題，而是你測試代碼中的邏輯問題，噢，MyGot，作為程序員的我。已經為邏輯代碼傷腦筋了。還要為測試代碼煩惱，做人真命苦啊。 想來也確實是這樣。

這就引申了另外一個問題，怎么樣才可以保證我邏輯代碼的可測性？

目的之二代碼的可維護性。

就拿上面的例子來說吧。只要我們的單元測試是正確的，那我們就可以保證無論你怎么修改那段代碼，只要測試代碼可以產生綠色條，那OK，你修改的邏輯代碼是正確的。當然可維護并非只有這點，還有，比如保證修改了這段代碼不會影響到其他的模塊等。

目的之三代碼的可擴展。

對于這點我理解很膚淺。只能表達表面的東西，希望。

對于可擴展我覺得保遵循一個代碼之間的耦合度降到最低。就OK了。單元測試對這方面有很強的好處，為了程序的可維護性，它可以強迫你寫低耦合度的程序。

單元測試的優點

1、它是一種驗證行為。

程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發提供支緩。就算是開發后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。

2、它是一種設計行為。

編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試（test-first），迫使我們把程序設計

成易于調用和可測試的，即迫使我們解除軟件中的耦合。

3、它是一種編寫文檔的行為。

單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。

4、它具有回歸性。

自動化的單元測試避免了代碼出現回歸，編寫完成之后，可以隨時隨地的快速運行測試。

單元測試的范疇

如果要給單元測試定義一個明確的范疇，指出哪些功能是屬于單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的范疇，單元測試所要做的工作。

1、 它的行為和我期望的一致嗎？

這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。

2、 它的行為一直和我期望的一致嗎？

編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一 致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致；譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。

3、 我可以依賴單元測試嗎？

不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。

4、 單元測試說明我的意圖了嗎？

單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。