詳解
單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明确的功能是否正确。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然後确認該值出現在list 的尾部。或者，你可能會從字符串中删除匹配某種模式的字符，然後确認字符串确實不再包含這些字符了。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這麼說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一緻。
工廠在組裝一台電視機之前，會對每個元件都進行測試，這，就是單元測試。
其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什麼的，這，也是單元測試，把這種單元測試稱為臨時單元測試。隻進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼複蓋率要超過70%都很困難，未複蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高後期測試和維護成本，也降低了開發商的競争力。可以說，進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。
對于程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。
要進行充分的單元測試，應專門編寫測試代碼，并與産品代碼隔離。我認為，比較簡單的辦法是為産品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談我的看法。
一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以我的實踐來看，以類作為測試單位，複雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。
有一種看法是，隻測試類的接口（公有函數），不測試其他函數，從面向對象角度來看，确實有其道理，但是，測試的目的是找錯并最終排錯，因此，隻要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫（inline函數），所有在源文件編寫實現的函數都要進行測試（構造函數和析構函數除外）。
使用效果
我們編寫代碼時，一定會反複調試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會願意交付給自己的老闆。但代碼通過編譯，隻是說明了它的語法正确；我們卻無法保證它的語義也一定正确，沒有任何人可以輕易承諾這段代碼的行為一定是正确的。
幸運的是，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一緻。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的後顧之憂。
什麼時候測試？單元測試越早越好，早到什麼程度？極限編程(Extreme Programming,或簡稱XP)講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什麼後什麼，重要的是高效和感覺舒适。從經驗來看，先編寫産品函數的框架，然後編寫測試函數，針對産品函數的功能編寫測試用例，然後編寫産品函數的代碼，每寫一個功能點都運行測試，随時補充測試用例。所謂先編寫産品函數的框架，是指先編寫函數空的實現，有返回值的直接返回一個合适值，編譯通過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該确定下來了，所編寫的測試代碼以後需修改的可能性比較小。
由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交産品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。
關于樁代碼，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，産品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用于實現測試隔離。采用由底向上的方式進行開發，底層的代碼先開發并先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，通過回歸測試可以确認修改是否導緻上層函數産生錯誤。
誤解
在明确了什麼是單元測試以後，我們可以進行"反調論證"了。在下面的章節裡，我們列出了一些反對單元測試的普遍的論點。然後用充分的理由來證明這些論點是不足取的。
它浪費了太多的時間
一旦編碼完成，開發人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。
在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實踐中，這樣一種開發步驟常常會導緻這樣的結果：軟件甚至無法運行。更進一步的結果是大量的時間将被花費在跟蹤那些包含在獨立單元裡的簡單的Bug上面，在個别情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導緻在軟件集成為一個系統時增加額外的工期， 而且當這個系統投入使用時也無法确保它能夠可靠運行。
在實踐工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大緻上是相同的。一旦完成了這些單元測試工作，很多Bug将被糾正，在确信他們手頭擁有穩定可靠的部件的情況下，開發人員能夠進行更高效的系統集成工作。這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式隻會花費更多的時間而取得很少的好處。
使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。
它僅僅是證明這些代碼做了什麼
這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨， 當編碼完成以後并且面臨代碼測試任務的時候，他們就閱讀這些代碼并找出它實際上做了什麼，把他們的測試工作基于已經寫好的代碼的基礎上。當然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住（希望能夠）罕見的編譯器Bug，但是他們能夠做的僅僅是這些。
如果他們首先寫好一個詳細的規格說明，測試能夠以規格說明為基礎。代碼就能夠針對它的規格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規格說明中的錯誤。好的規格說明可以使測試的質量更高，所以最後的結論是高質量的測試需要高質量的規格說明。
在實踐中會出現這樣的情況：一個開發人員要面對測試一個單元時隻給出單元的代碼而沒有規格說明這樣吃力不讨好的任務。你怎樣做才會有更多的收獲，而不僅僅是發現編譯器的Bug？第一步是理解這個單元原本要做什麼， --- 不是它實際上做了什麼。比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。可以組織對這個概要規格說明的走讀（Review)，以确保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設計單元測試了。
我是個很棒的程序員， 我是不是可以不進行單元測試？
在每個開發組織中都至少有一個這樣的開發人員，他非常擅長于編程，他們開發的軟件總是在第一時間就可以正常運行，因此不需要進行測試。你是否經常聽到這樣的借口？
在真實世界裡，每個人都會犯錯誤。即使某個開發人員可以抱着這種态度在很少的一些簡單的程序中應付過去。但真正的軟件系統是非常複雜的。真正的軟件系統不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。
編碼不是一個可以一次性通過的過程。在真實世界中，軟件産品必須進行維護以對操作需求的改變作出反應， 并且要對最初的開發工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎？ 這些制造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方制造這樣的代碼。在開發人員做出修改後進行可重複的單元測試可以避免産生那些令人不快的負作用。
不管怎樣，集成測試将會抓住所有的Bug。
我們已經在前面的讨論中從一個側面對這個問題進行了部分的闡述。這個論點不成立的原因在于規模越大的代碼集成意味着複雜性就越高。如果軟件的單元沒有事先進行測試，開發人員很可能會花費大量的時間僅僅是為了使軟件能夠運行，而任何實際的測試方案都無法執行。
一旦軟件可以運行了，開發人員又要面對這樣的問題：在考慮軟件全局複雜性的前提下對每個單元進行全面的測試。這是一件非常困難的事情，甚至在創造一種單元調用的測試條件的時候，要全面的考慮單元的被調用時的各種入口參數。在軟件集成階段，對單元功能全面測試的複雜程度遠遠的超過獨立進行的單元測試過程。
最後的結果是測試将無法達到它所應該有的全面性。一些缺陷将被遺漏，并且很多Bug将被忽略過去。
讓我們類比一下，假設我們要清洗一台已經完全裝配好的食物加工機器！無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機器的死角位置，隻有任其腐爛并等待以後再想辦法。但我們換個角度想想，如果這台機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費力的進行清洗。
成本效率
一個特定的開發組織或軟件應用系統的測試水平取決于對那些未發現的Bug的潛在後果的重視程度。這種後果的嚴重程度可以從一個Bug引起的小小的不便到發生多次的死機的情況。這種後果可能常常會被軟件的開發人員所忽視（但是用戶可不會這樣），這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發組織的信譽，并且會導緻對未來的市場産生負面的影響。相反地，一個可靠的軟件系統的良好的聲譽将有助于一個開發組織獲取未來的市場。
很多研究成果表明，無論什麼時候作出修改都需要進行完整的回歸測試，在生命周期中盡早地對軟件産品進行測試将使效率和質量都得到最好的保證。Bug發現的越晚，修改它所需的費用就越高，因此從經濟角度來看， 應該盡可能早的查找和修改Bug。在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。
相比後階段的測試，單元測試的創建更簡單，維護更容易，并且可以更方便的進行重複。從全程的費用來考慮， 相比起那些複雜且曠日持久的集成測試，或是不穩定的軟件系統來說，單元測試所需的費用是很低的。
相關圖表
這些圖表摘自<<實用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準備測試，執行測試，和修改缺陷所花費的時間（以一個功能點為基準），這些數據顯示單元測試的成本效率大約是集成測試的兩倍系統測試的三倍（參見條形圖）。
(術語域測試（Field test)意思是在軟件投入使用以後，針對某個領域所作的所有測試活動）
這個圖表并不表示開發人員不應該進行後階段的測試活動，這次測試活動仍然是必須的。它的真正意思是盡可能早的排除盡可能多的Bug可以減少後階段測試的費用。
其他的一些圖表顯示高達50%的維護工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發階段被排除掉的話，這些工作量就可以節省下來。當考慮到軟件維護費用可能會比最初的開發費用高出數倍的時候，這種潛在的對50%軟件維護費用的節省将對整個軟件生命周期費用産生重大的影響。
結論
經驗表明一個盡責的單元測試方法将會在軟件開發的某個階段發現很多的Bug，并且修改它們的成本也很低。在軟件開發的後期階段，Bug的發現并修改将會變得更加困難，并要消耗大量的時間和開發費用。無論什麼時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件産品進行測試将使效率和質量得到最好的保證。在提供了經過測試的單元的情況下，系統集成過程将會大大地簡化。開發人員可以将精力集中在單元之間的交互作用和全局的功能實現上，而不是陷入充滿很多Bug的單元之中不能自拔。
使測試工作的效力發揮到最大化的關鍵在于選擇正确的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有适當地使用象AdaTEST和Cantata這樣的工具來支持測試過程。這些活動可以産生這樣的結果：在花費更低的開發費用的情況下得到更穩定的軟件。更進一步的好處是簡化了維護過程并降低了生命周期的費用。有效的單元測試是推行全局質量文化的一部分，而這種質量文化将會為軟件開發者帶來無限的商機。
優點
1、它是一種驗證行為。
程序中的每一項功能都是測試來驗證它的正确性。它為以後的開發提供支援。就算是開發後期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。
2、它是一種設計行為。
編寫單元測試将使我們從調用者觀察、思考。特别是先寫測試（test-first），迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。
3、它是一種編寫文檔的行為。
單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。
4、它具有回歸性。
自動化的單元測試避免了代碼出現回歸，編寫完成之後，可以随時随地的快速運行測試。
範疇
如果要給單元測試定義一個明确的範疇，指出哪些功能是屬于單元測試，這似乎很難。但下面讨論的四個問題，基本上可以說明單元測試的範疇，單元測試所要做的工作。
1、 它的行為和我期望的一緻嗎？
這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。
2、 它的行為一直和我期望的一緻嗎？
編寫單元測試，如果隻測試代碼的一條正确路徑，讓它正确走一遍，并不算是真正的完成。軟件開發是一項複雜的工程，在測試某段代碼的行為是否和你的期望一緻時，你需要确認：在任何情況下，這段代碼是否都和你的期望一緻；譬如參數很可疑、硬盤沒有剩餘空間、緩沖區溢出、網絡掉線的時候。
3、 我可以依賴單元測試嗎？
不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正确性，那麼單元測試也一定要值得依賴。
4、 單元測試說明我的意圖了嗎？
單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。
不寫的借口
到這裡，我們已經列舉了使用單元測試的種種理由。也許，每個人都同意，是的，該做更多的測試。這種人人同意的事情還多着呢，是的，該多吃蔬菜，該戒煙，該多休息，該多鍛煉……這并不意味着我們中的所有人都會這麼去做，不是嗎？
1、 編寫單元測試太花時間了。
我們知道，在開發時越早發現BUG，就能節省更多的時間，降低更多的風險。
下圖表摘自<<實用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準備測試，執行測試，和修改缺陷所花費的時間（以一個功能點為基準），這些數據顯示單元測試的成本效率大約是集成測試的兩倍，是系統測試的三倍（參見條形圖）。
術語：域測試（Field test)意思是在軟件投入使用以後，針對某個領域所作的所有測試活動。
如果你仍然認為在編寫産品代碼的時候，還是沒有時間編寫測試代碼，那麼請先考慮下面這些問題：
1）、對于所編寫的代碼，你在調試上面花了多少時間。
2）、對于以前你自認為正确的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新确認這些代碼上面。
3）、對于一個别人報告的bug，你花了多少時間才找出導緻這個bug 的源碼位置。
回答完這些問題，你一定不再以“太花時間”作為拒絕單元測試的借口。
2、 運行測試的時間太長了。
合适的測試是不會讓這種情況發生的。實際上，大多數測試的執行都是非常快的，因此你在幾秒之内就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時，需要把這些耗時的測試和其他測試分開。通常可以每天運行這種測試一次，或者幾天一次。
3、 測試代碼并不是我的工作。
你的工作就是保證代碼能夠正确的完成你的行為，恰恰相反，測試代碼正是你不可缺少的工作。
4、 我并不清楚代碼的行為，所以也就無從測試。
如果你實在不清楚代碼的行為，那麼估計現在并不是編碼的時候。如果你并不知道代碼的行為，那麼你又如何知道你編寫的代碼是正确的呢
5、 但是這些代碼都能夠編譯通過。
我們前面已經說過，代碼通過編譯隻是驗證它的語法通過。但并不能保證它的行為就一定正确。
6、 公司請我來是為了寫代碼，而不是寫測試。
公司付給你薪水是為了讓你編寫産品代碼，而單元測試大體上是一個工具，是一個和編輯器、開發環境、編譯器等處于同一位置的工具。
7、 如果我讓測試員或者QA（Quality Assurance）人員沒有工作，那麼我會覺得很内疚。
你并不需要擔心這些。請記住，我們在此隻是談論單元測試，而它隻是一種針對源碼的、低層次的，為程序員而設計的測試。在整個項目中，還有其他的很多測試需要這些人來完成，如：功能測試、驗收測試、性能測試、環境測試、有效性測試、正确性測試、正規分析等等。
8、 我的公司并不會讓我在真實系統中運行單元測試。
我們所讨論的隻是針對開發者的單元測試。也就是說，如果你可以在其他的環境下（例如在正式的産品系統中）運行這些測試的話，那麼它們就不再是單元測試，而是其他類型的測試了。實際上，你可以在你的本機運行單元測試，使用你自己的數據庫，或者使用mock 對象。
代碼編寫
多數講述單元測試的文章都是以Java為例，本文以C++為例，後半部分所介紹的單元測試工具也隻介紹C++單元測試工具。下面的示例代碼的開發環境是VC6.0。
産品類
class CMyClass
{
public:
int Add(int i,int j);
CMyClass();
virtual ~CMyClass();
private:
int mAge; //年齡
CString mPhase; //年齡階段，如"少年"，"青年"
};
建立對應的測試類CMyClassTester，為了節約編幅，隻列出源文件的代碼：
void CMyClassTester::CaseBegin()
{
//pObj是CMyClassTester類的成員變量，是被測試類的對象的指針，
//為求簡單，所有的測試類都可以用pObj命名被測試對象的指針。
pObj = new CMyClass();
}
void CMyClassTester::CaseEnd()
{
delete pObj;
}
測試類的函數CaseBegin()和CaseEnd()建立和銷毀被測試對象，每個測試用例的開頭都要調用CaseBegin()，結尾都要調用CaseEnd()。
産品函數
接下來，我們建立示例的産品函數：
int CMyClass::Add(int i,int j)
{
return i+j;
}
和對應的測試函數：
void CMyClassTester::Add_int_int()
{
}
把參數表作為函數名的一部分，這樣當出現重載的被測試函數時，測試函數不會産生命名沖突。下面添加測試用例：
void CMyClassTester::Add_int_int()
{
//第一個測試用例
CaseBegin();{ //1
int i = 0; //2
int j = 0; //3
int ret = pObj->Add(i,j); //4
ASSERT(ret == 0); //5
}CaseEnd(); //6
}
解釋
第1和第6行建立和銷毀被測試對象，所加的{}是為了讓每個測試用例的代碼有一個獨立的域，以便多個測試用例使用相同的變量名。
第2和第3行是定義輸入數據，第4行是調用被測試函數，這些容易理解，不作進一步解釋。第5行是預期輸出，它的特點是當實際輸出與預期輸出不同時自動報錯，ASSERT是VC的斷言宏，也可以使用其他類似功能的宏，使用測試工具進行單元測試時，可以使用該工具定義的斷言宏。
示例中的格式顯得很不簡潔，2、3、4、5行可以合寫為一行：ASSERT(pObj->Add(0,0) == 0);但這種不簡潔的格式卻是老納極力推薦的，因為它一目了然，易于建立多個測試用例，并且具有很好的适應性，同時，也是極佳的代碼文檔，總之，老納建議：輸入數據和預期輸出要自成一塊。
建立了第一個測試用例後，應編譯并運行測試，以排除語法錯誤，然後，使用拷貝/修改的辦法建立其他測試用例。由于各個測試用例之間的差别往往很小，通常隻需修改一兩個數據，拷貝/修改是建立多個測試用例的最快捷辦法。
測試用例
下面說說測試用例、輸入數據及預期輸出。輸入數據是測試用例的核心，對輸入數據的定義是：被測試函數所讀取的外部數據及這些數據的初始值。外部數據是對于被測試函數來說的，實際上就是除了局部變量以外的其他數據，老納把這些數據分為幾類：參數、成員變量、全局變量、IO媒體。IO媒體是指文件、數據庫或其他儲存或傳輸數據的媒體，例如，被測試函數要從文件或數據庫讀取數據，那麼，文件或數據庫中的原始數據也屬于輸入數據。一個函數無論多複雜，都無非是對這幾類數據的讀取、計算和寫入。預期輸出是指：返回值及被測試函數所寫入的外部數據的結果值。返回值就不用說了，被測試函數進行了寫操作的參數（輸出參數）、成員變量、全局變量、IO媒體，它們的預期的結果值都是預期輸出。一個測試用例，就是設定輸入數據，運行被測試函數，然後判斷實際輸出是否符合預期。下面舉一個與成員變量有關的例子：
産品函數
void CMyClass::Grow(int years)
{
mAge += years;
if(mAge < 10)
mPhase = "兒童";
else if(mAge <20)
mPhase = "少年";
else if(mAge <45)
mPhase = "青年";
else if(mAge <60)
mPhase = "中年";
else
mPhase = "老年";
}
測試函數中的一個測試用例：
CaseBegin();{
int years = 1;
pObj->mAge = 8;
pObj->Grow(years);
ASSERT( pObj->mAge == 9 );
ASSERT( pObj->mPhase == "兒童" );
}CaseEnd();
在輸入數據中對被測試類的成員變量mAge進行賦值，在預期輸出中斷言成員變量的值。現在可以看到老納所推薦的格式的好處了吧，這種格式可以适應很複雜的測試。在輸入數據部分還可以調用其他成員函數，例如：執行被測試函數前可能需要讀取文件中的數據保存到成員變量，或需要連接數據庫，老納把這些操作稱為初始化操作。例如，上例中 ASSERT( ...)之前可以加pObj->OpenFile();。為了訪問私有成員，可以将測試類定義為産品類的友元類。例如，定義一個宏：
#define UNIT_TEST(cls) friend class cls##Tester;
然後在産品類聲明中加一行代碼：UNIT_TEST(ClassName)。
測試用例設計
下面談談測試用例設計。前面已經說了，測試用例的核心是輸入數據。預期輸出是依據輸入數據和程序功能來确定的，也就是說，對于某一程序，輸入數據确定了，預期輸出也就可以确定了，至于生成/銷毀被測試對象和運行測試的語句，是所有測試用例都大同小異的，因此，我們讨論測試用例時，隻讨論輸入數據。
前面說過，輸入數據包括四類：參數、成員變量、全局變量、IO媒體，這四類數據中，隻要所測試的程序需要執行讀操作的，就要設定其初始值，其中，前兩類比較常用，後兩類較少用。顯然，把輸入數據的所有可能取值都進行測試，是不可能也是無意義的，我們應該用一定的規則選擇有代表性的數據作為輸入數據，主要有三種：正常輸入，邊界輸入，非法輸入，每種輸入還可以分類，也就是平常說的等價類法，每類取一個數據作為輸入數據，如果測試通過，可以肯定同類的其他輸入也是可以通過的。下面舉例說明：
正常輸入
例如字符串的Trim函數，功能是将字符串前後的空格去除，那麼正常的輸入可以有四類：前面有空格；後面有空格；前後均有空格；前後均無空格。
邊界輸入
上例中空字符串可以看作是邊界輸入。
再如一個表示年齡的參數，它的有效範圍是0-100，那麼邊界輸入有兩個：0和100。
非法輸入
非法輸入是正常取值範圍以外的數據，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數，小于0或大于100都是非法輸入，再如一個進行文件操作的函數，非法輸入有這麼幾類：文件不存在；目錄不存在；文件正在被其他程序打開；權限錯誤。
如果函數使用了外部數據，則正常輸入是肯定會有的，而邊界輸入和非法輸入不是所有函數都有。一般情況下，即使沒有設計文檔，考慮以上三種輸入也可以找出函數的基本功能點。實際上，單元測試與代碼編寫是“一體兩面”的關系，編碼時對上述三種輸入都是必須考慮的，否則代碼的健壯性就會成問題。
白盒複蓋
上面所說的測試數據都是針對程序的功能來設計的，就是所謂的黑盒測試。單元測試還需要從另一個角度來設計測試數據，即針對程序的邏輯結構來設計測試用例，就是所謂的白盒測試。在老納看來，如果黑盒測試是足夠充分的，那麼白盒測試就沒有必要，可惜“足夠充分”隻是一種理想狀态，例如：真的是所有功能點都測試了嗎？程序的功能點是人為的定義，常常是不全面的；各個輸入數據之間，有些組合可能會産生問題，怎樣保證這些組合都經過了測試？難于衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易于衡量測試完整性的優點，兩者之間具有極好的互補性，例如：完成功能測試後統計語句複蓋率，如果語句複蓋未完成，很可能是未複蓋的語句所對應的功能點未測試。
白盒測試針對程序的邏輯結構設計測試用例，用邏輯複蓋率來衡量測試的完整性。邏輯單位主要有：語句、分支、條件、條件值、條件值組合，路徑。語句複蓋就是複蓋所有的語句，其他類推。另外還有一種判定條件複蓋，其實是分支複蓋與條件複蓋的組合，在此不作讨論。
跟條件有關的複蓋就有三種，解釋一下：條件複蓋是指複蓋所有的條件表達式，即所有的條件表達式都至少計算一次，不考慮計算結果；條件值複蓋是指複蓋條件的所有可能取值，即每個條件的取真值和取假值都要至少計算一次；條件值組合複蓋是指複蓋所有條件取值的所有可能組合。老納做過一些粗淺的研究，發現與條件直接有關的錯誤主要是邏輯操作符錯誤，例如：||寫成&&，漏了寫！什麼的，采用分支複蓋與條件複蓋的組合，基本上可以發現這些錯誤，另一方面，條件值複蓋與條件值組合複蓋往往需要大量的測試用例，因此，在老納看來，條件值複蓋和條件值組合複蓋的效費比偏低。效費比較高且完整性也足夠的測試要求是這樣的：完成功能測試，完成語句複蓋、條件複蓋、分支複蓋、路徑複蓋。
做過單元測試的朋友恐怕會對老納提出的測試要求給予一個字的評價：暈！或者兩個字的評價：狂暈！因為這似乎是不可能的要求，要達到這種測試完整性，其測試成本是不可想象的，不過，出家人不打逛語，老納之所以提出這種測試要求，是因為利用一些工具，可以在較低的成本下達到這種測試要求，後面将會作進一步介紹。
關于白盒測試用例的設計，程序測試領域的書籍一般都有講述，普通方法是畫出程序的邏輯結構圖如程序流程圖或控制流圖，根據邏輯結構圖設計測試用例，這些是純粹的白盒測試，不是老納想推薦的方式。老納所推薦的方法是：先完成黑盒測試，然後統計白盒複蓋率，針對未複蓋的邏輯單位設計測試用例複蓋它，例如，先檢查是否有語句未複蓋，有的話設計測試用例複蓋它，然後用同樣方法完成條件複蓋、分支複蓋和路徑複蓋，這樣的話，既檢驗了黑盒測試的完整性，又避免了重複的工作，用較少的時間成本達到非常高的測試完整性。不過，這些工作可不是手工能完成的，必須借助于工具，後面會介紹可以完成這些工作的測試工具。
測試工具
現在開始介紹單元測試工具，分别按編程語言進行分組介紹。
C/C++
CppUnit
首先是CppUnit，這是C++單元測試工具的鼻祖，免費的開源的單元測試框架。由于已有一衆高人寫了不少關于CppUnit的很好的文章，老納就不現醜了，想了解CppUnit的朋友，建議讀一下Cpluser 所作的《CppUnit測試框架入門》，。該文也提供了CppUnit的下載地址。
C++Test
然後介紹C++Test，這是Parasoft公司的産品。[C++Test是一個功能強大的自動化C/C++單元級測試工具，可以自動測試任何C/C++函數、類，自動生成測試用例、測試驅動函數或樁函數，在自動化的環境下極其容易快速的将單元級的測試複蓋率達到100%]。[]内的文字引自，這是華唐公司的網頁。老納想寫些介紹C++Test的文字，但發現無法超越華唐公司的網頁上的介紹，所以也就省點事了，想了解C++Test的朋友，建議訪問該公司的網站。華唐公司代理C++Test，想要購買或索取報價、試用版都可以找他們。
Visual Unit
最後介紹Visual Unit，簡稱VU，這是國産的單元測試工具，據說申請了多項專利，擁有一批創新的技術，不過老納隻關心是不是有用和好用。[自動生成測試代碼 快速建立功能測試用例程序行為一目了然 極高的測試完整性 高效完成白盒複蓋 快速排錯 高效調試 詳盡的測試報告]。[]内的文字是VU開發商的網頁上摘錄的，。前面所述測試要求：完成功能測試，完成語句複蓋、條件複蓋、分支複蓋、路徑複蓋，用VU可以輕松實現，還有一點值得一提：使用VU還能提高編碼的效率，總體來說，在完成單元測試的同時，編碼調試的時間還能大幅度縮短。
算了，不想再講了，老納顯擺理論、介紹經驗還是有興趣的，因為可以滿足老納好為人師的虛榮心，但介紹工具就覺得索然無味了，畢竟工具好不好用，合不合用，要試過才知道，還是自己去開發商的網站看吧，可以下載演示版，還有演示課件。
gtest
gtest測試框架是在不同平台上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）為編寫C++測試而生成的。它是基于xUnit架構的測試框架，支持自動發現測試，豐富的斷言集，用戶定義的斷言，death測試，緻命與非緻命的失敗，類型參數化測試，各類運行測試的選項和XML的測試報告。需要詳細了解的朋友可以參閱《玩轉Google單元測試框架gtest系列》該篇文章。
C#
Visual Build Professional
Java
JUnit
JUnit 是 Java 社區中知名度最高的單元測試工具。它誕生于 1997 年，由 Erich Gamma 和 Kent Beck 共同開發完成。其中 Erich Gamma 是經典着作《設計模式：可複用面向對象軟件的基礎》一書的作者之一，并在 Eclipse 中有很大的貢獻；Kent Beck 則是一位極限編程（XP）方面的專家和先驅。JUnit 設計的非常小巧，但是功能卻非常強大。JUnit ——是一個開發源代碼的Java測試框架，用于編寫和運行可重複的測試。他是用于單元測試框架體系xUnit的一個實例（用于java語言）。主要用于白盒測試，回歸測試。
JUnit的好處和JUnit單元測試編寫原則：
好處：可以使測試代碼與産品代碼分開；針對某一個類的測試代碼通過較少的改動便可以應用于另一個類的測試；易于集成到測試人員的構建過程中，JUnit和Ant的結合可以實施增量開發；JUnit是公開源代碼的，可以進行二次開發；可以方便地對JUnit進行擴展；
編寫原則：是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫；是使測試單元保持持久性；是可以利用既有的測試來編寫相關的測試；
JUnit使用幫助
1、junit3.x版本，我們通常使用junit 3.8
(1)、使用junit3.x版本進行單元測試時，測試類必須要繼承于TestCase父類；
(2)、測試方法需要遵循的原則：
A、public的
B、void的
C、無方法參數
D、方法名稱必須以test開頭
(3)、不同的Test Case之間一定要保持完全的獨立性，不能有任何的關聯。
(4)、我們要掌握好測試方法的順序，不能依賴于測試方法自己的執行順序。
dome:
public class TestMyNumber extends TestCase {
private MyNumber myNumber;
public TestMyNumber(String name) {
super(name);
}
// 在每個測試方法執行 [之前] 都會被調用
@Override
public void setUp() throws Exception {
// System.out.println("歡迎使用Junit進行單元測試…");
myNumber = new MyNumber();
}
// 在每個測試方法執行 [之後] 都會被調用
@Override
public void tearDown() throws Exception {
// System.out.println("Junit單元測試結束…");
}
public void testDivideByZero() {
Throwable te = null;
try {
myNumber.divide(6, 0);
Assert.fail("測試失敗");
} catch (Exception e) {
e.printStackTrace();
te = e;
}
Assert.assertEquals(Exception.class, te.getClass());
Assert.assertEquals("除數不能為 0 ", te.getMessage());
}
}
2、junit4.x版本
(1)、使用junit4.x版本進行單元測試時，不用測試類繼承TestCase父類，因為，junit4.x全面引入了Annotation來執行我們編寫的測試。
(2)、junit4.x版本，引用了注解的方式，進行單元測試；
(3)、junit4.x版本我們常用的注解：
A、@Before 注解：與junit3.x中的setUp()方法功能一樣，在每個測試方法之前執行；
B、@After 注解：與junit3.x中的tearDown()方法功能一樣，在每個測試方法之後執行；
C、@BeforeClass 注解：在所有方法執行之前執行；
D、@AfterClass 注解：在所有方法執行之後執行；
E、@Test(timeout = xxx) 注解：設置當前測試方法在一定時間内運行完，否則返回錯誤；
F、@Test(expected = Exception.class) 注解：設置被測試的方法是否有異常抛出。抛出異常類型為：Exception.class；
G、@Ignore 注解：注釋掉一個測試方法或一個類，被注釋的方法或類，不會被執行。
dome:
package com.an.junit;
import static org.junit.Assert.*;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
public class TestMyNumber {
private MyNumber myNumber;
@BeforeClass
// 在所有方法執行之前執行
public static void globalInit() {
System.out.println("init all method...");
}
@AfterClass
// 在所有方法執行之後執行
public static void globalDestory() {
System.out.println("destory all method...");
}
@Before
// 在每個測試方法之前執行
public void setUp() {
System.out.println("start setUp method");
myNumber = new MyNumber();
}
@After
// 在每個測試方法之後執行
public void tearDown() {
System.out.println("end tearDown method");
}
@Test(timeout=600)// 設置限定測試方法的運行時間 如果超出則返回錯誤
public void testAdd() {
System.out.println("testAdd method");
int result = myNumber.add(2, 3);
assertEquals(5, result);
}
@Test
public void testSubtract() {
System.out.println("testSubtract method");
int result = myNumber.subtract(1, 2);
assertEquals(-1, result);
}
@Test
public void testMultiply() {
System.out.println("testMultiply method");
int result = myNumber.multiply(2, 3);
assertEquals(6, result);
}
@Test
public void testDivide() {
System.out.println("testDivide method");
int result = 0;
try {
result = myNumber.divide(6, 2);
} catch (Exception e) {
fail();
}
assertEquals(3, result);
}
@Test(expected = Exception.class)
public void testDivide2() throws Exception {
System.out.println("testDivide2 method");
myNumber.divide(6, 0);
fail("test Error");
}
public static void main(String[] args) {
}
}
有興趣的朋友可以下下來仔細研究下，也可以到安安DIY創作室博客一起讨論一下。
JUnit-addons
對JUnit的一些補充，比如設置、獲取被測試對象的私有屬性的值，調用被測試對象的私有方法等。
常用類：junitx.util.PrivateAccessor
Spring 測試框架
可以測試基于Spring的應用，通過配置文件和注解自動組裝需要的單元測試對象。
提供了一些常用的J2EE Mock對象，比如HttpSession的Mock類等。
可以支持數據庫自動回滾，以防止對數據庫的單元測試（插入，删除等）不可重複執行，防止修改數據庫狀态等。
DJUnit
通過代碼自動産生Mock對象，省去了自己手動編寫N多的Mock類。
此外，它的Eclipse插件還可以做到測試複蓋率、分支統計。
EasyMock
功能同DJUnit，也是通過編程自動Mock掉與測試對象無關的類，方法。
3、因為在測試過程中可能不能同時run所有的測試用例，或者是想同時run不同的測試用例或所有的用例，那麼我們要維護一個公共的Suite，這個Suite可以添加TestSuite或一個單個用例（測試函數）。nTestCase->TestSuite，Testmethods->TestSuiten舉例說明：package calculor.Calculor;nimport static org.junit.Assert.*;nimport junit.framework.TestCase;nimport org.junit.After;nimport org.junit.Before;nimport org.junit.Test;npublic class CalcTest extends TestCase {n @Beforen public void setUp() throws Exception {n }n @Aftern public void tearDown() throws Exception {n }n @Testn public void testAdd() {n //fail("Not yet implemented");n assertEquals(2， 2);n }n}n另外一個TestCase集合類npackage calculor.Calculor;nimport static org.junit.Assert.*;nimport junit.framework.TestCase;nimport org.junit.After;nimport org.junit.Before;nimport org.junit.Test;npublic class TTmmTest extends TestCase {n public TTmmTest(){}n public TTmmTest (String name){n super(name);n }//注意這裡添加了這個構造函數，因為要調用父類的構造函數，用于下面Suite添加該類的測試方法n @Beforen public void setUp() throws Exception {n }n @Aftern public void tearDown() throws Exception {n }n @Testn public void testHelloworld() {n //fail("Not yet implemented");n assertEquals(2，2);n }n}
國内現狀
國内目前很多軟件公司的單元測試還很不正規，隻是由開發人員來簡單地編譯和調試一下自己的程序，沒有相應的單元測試計劃、單元測試用例和代碼複蓋率的統計。對于單元測試這個環節，很多都是走過場的。不少程序員覺得任務大、時間趕、人手少，一接到任務就是先趕代碼完成工作量了，這其實是很普遍的現象.。而且，絕大部分程序員從骨子裡不喜歡寫單元測試，這是不争的事實。
如何給程序員減壓，但又能做好單元測試呢?
中小企業的程序員和項目經理，一般面對的都是壓力大、任務重的項目。 如果作為項目經理的你，覺得測試組有人(有人就行了,多少倒不大重要)，不妨讓測試組的人早點介入單元測試，又或者假如測試組的人起碼能寫點代碼，那其實更好，那麼分配測試組的人去寫單元測試，這其實是很有好處的。
這其中有一個值得一提的問題，大部分業務可以确定下來，但并非全部的業務。很多時候連客戶不知道自己真正要什麼，實現了之後客戶不滿意，就要再整理需求再改代碼。這種情況決定了不可能先寫測試再寫實現，如果隻寫實現，那麼客戶要求改時隻改實現代碼，如果是先寫單元測試，那麼改程序的時候要改兩份代碼。
是不是可以這樣？已經确定的業務，讓程序員和測試人員在動手寫一個模塊前，先讓他們讨論這個模塊的單元測試策略，這樣可以減輕程序員的負擔。雙方指定單元測試的框架流程，程序員不編寫單元測試代碼，但由于程序員參與了讨論，因此心裡會更清楚。由測試人員編寫單元測試代碼。 程序員寫完代碼後，由測試人員編寫的單元測試代碼去對碰程序員的代碼，得出相關的測試報告。好處是，職責分離了，測試組的人能提前介入，對以後的集成測試很有好處，而且可以讓測試人員寫點測試代碼，好讓他們不閑着，有點成就感。而且程序員的負擔減少了，雖然程序員不寫單元測試代碼了，但由于一開始跟測試人員在一起，會對測試流程熟悉，對代碼編寫很有好處。對于沒有确定的業務，就暫時先實現。
千萬不要等到項目後期再進行單元測試，那樣就失去檢查代碼、預防缺陷的意義了。
應用
極限編程
單元測試是極限編程的基礎，依賴于自動化的單元測試框架。自動化的單元測試框架可以來源于第三方，如xUnit，也可以由開發組自己創建。
極限編程創建單元測試用于測試驅動開發。首先，開發人員編寫單元測試用于展示軟件需求或者軟件缺陷。因為需求尚未實現或者現有代碼中存在軟件缺陷，這些測試會失敗。然後，開發人員遵循測試要求編寫最簡單的代碼去滿足它，直到測試得以通過。
系統中大多數代碼都經過單元測試，但并非所有代碼路徑都必需單元測試。極限編程強調“測試所有可能中斷”的策略，而傳統方法是“測試所有執行路徑”。這使得極限編程開發人員比傳統開發少寫單元測試，但這并不是問題。不争的事實是傳統方法很少完全遵循完整地測試所有執行路徑的要求。極限編程相互地認識到測試很少能完備（因為完備測試通常需要昂貴的代價和時間消耗，意味着不經濟），提供了如何有效地将有限資源集中投入可花費的代價到問題關鍵的導引。
至關重要的，測試代碼應視為第一個項目成品，與實現代碼維持同等級别的質量要求，沒有重複。開發人員在提交程序單元代碼時一并提交單元測試代碼到代碼庫。徹底的極限編程單元測試代碼提供上述單元測試的收益，如簡化和更可信的程序開發和重構、簡化代碼集成、精确的文檔和模塊化的設計。而且，單元測試經常作為複合測試的一種形式被運行。
技術
單元測試通常情況下自動進行，但也可被手動執行。IEEE沒有偏愛某一種形式。手動的單元測試可用于step-by-step的教學文檔。盡管如此，單元測試的目标是隔離程序單元并驗證其正确性。自動執行使目标達成更有效，也可獲得本文上述單元測試收益。相反，不細心規劃或者精心的單元測試可能被視為包括多個軟件組件的集成測試案例，于是将因未完全達到創建單元測試的預定目标，測試可能失去較多收益。
在自動化測試時，為了實現隔離的效果，測試将脫離待測程序單元（或代碼主體）本身固有的運行環境之外，即脫離産品環境或其本身被創建和調用的上下文環境，而在測試框架中運行。以隔離方式運行有利于充分顯露待測試代碼與其它程序單元或者産品數據空間的依賴關系。這些依賴關系在單元測試中可以被消除。
借助于自動化測試框架，開發人員可以抓住關鍵進行編碼并通過測試去驗證程序單元的正确性。在測試案例執行期間，框架通過日志記錄了所有失敗的測試準則。很多測試框架可以自動标記和提交失敗的測試案例總結報告。根據失敗的程度不同，框架可以中止後續測試。
總體說來，單元測試會激發程序員創造解耦的和内聚的代碼體。單元測試實踐有利于促進健康的軟件開發習慣。設計模式、單元測試和重構經常一起出現在工作中，借助于它們，開發人員可以生産出最為完美的解決方案。
單元測試框架
單元測試框架通常是沒有作為編譯器包的第三方産品。他們幫助簡化單元測試的過程，并且已經為各種編程語言開發。
通常在沒有特定框架支持下，通過撰寫在測試中的運行單元，并使用判定、異常處理、或其他控制流程機制來表示失敗的用戶代碼（client code）運行單元測試是可行的。不通過框架的單元測試有用之處在于進行單元測試時會有一個參進障礙（barrier to entry）；進行一點單元測試幾乎不比沒做好多少，但是一旦使用了框架，加入單元測試相對來說會簡單許多。在某些框架中許多先進單元測試特征丢失了或者必須是手工編寫的。
語言層單元測試支持
某些編程語言直接支持單元測試。他們的語法允許直接進行單元測試的聲明而不需要導入（不管是第三方的或标準的）。除此之外，單元測試的布爾條件可以用與非單元測試碼的布爾表示法相同的語法來表示，例如if和while聲明的用法。
直接支持單元測試的語言包含了：
C#
D語言
