java程序員如何編寫更好的單元測試的7個技巧

詳解

cppunit進行單元測試

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

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

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

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

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

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

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

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