單元測試是保證代碼質量最基本的手段，但是現在的開發中卻對單元測試不夠重視。有的人認為編譯器就是我們的代碼質量保證，還有的人認為正確的調試就是測試，還有的人認為使用這個軟件就是測試，這樣的認識都是存在問題的。下面講講怎么樣的單元測試才是好的單元測試。
單元測試應該準確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：
一、 單元測試應該在最低的功能/參數上驗證程序的正確性；
單元測試應該測試程序中最基本的單元——如C#中的類，在此基礎上，可以測試一些系統中最基本的功能點（這些功能點由幾個基本類組成），從面向對象的設計原理出發，系統中最基本的功能點也應該由一個類及其方法來表現。單元測試要測試API中的每一個方法及每一個參數。
二、 單元測試必須由最熟悉代碼的人（程序的作者）來寫；
代碼的作者最了解代碼的目的、特點和實現的局限性。所以沒有比作者更合適的人選。
就算作者沒有時間寫測試代碼，也應該對此單元測試進行負責。
三、 單元測試過后，機器狀態保持不變；
如果單元測試創建了臨時的文件或者目錄，在數據庫中創建或修改了記錄，都要刪除臨時數據。保證單元測試可以重復快速進行；
四、 單元測試要快（一個測試運行時間是幾秒鐘，而不是幾分鐘）；
快，才能保證效率。一個軟件中有幾十個基本模塊（類），每個模塊又有幾個方法，基本上要求一個類的測試在幾秒鐘內完成。如果軟件有相互獨立的幾個層次，那么在測試組中進行分類，分類進行測試。比如我只修改了“用戶界面”的代碼，我只需要運行“用戶界面”的單元測試。
五、 單元測試應該產生可重復，一致的結果；
如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復的。一般情況下不要使用隨機數以增加測試的真實性。
六、 獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構造數據以保持單元測試的獨立性；
程序中的各個模塊都是相互依賴的，一般情況下，單元測試中的模塊可以直接引用其它的模塊，并期待其它的模塊能返回正確的結果。如果其它模塊很不穩定、未完成，或者運行比較費時，這是可以人為地構造數據以保證這個單元測試的獨立性。
七、 單元測試應該覆蓋所有的代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，單元測試必須測試公開的和私有的函數/方法；
如果你的模塊中某個錯誤處理路徑很難到達，那你要想想是否可以把這個錯誤處理拿掉。要注意一點：100%的代碼覆蓋率并不等同于100%的正確性。
八、 單元測試應該集成到自動測試的框架中；
一個重要的措施是要把測試自動化，這樣每個人都能很容易地運行單元測試。團隊一般在每日構建（在敏捷開發中要求每天都能夠提供一個可以運行的版本進行構建）中運行單元測試，這樣每個單元測試的錯誤就能及時發現并得到修改。
九、 單元測試必須和產品代碼一起保存和維護。
單元測試必須和代碼一起進行版本維護。如果不是這樣，過一陣代碼和單元測試就會出現不一致，而且所有代碼的作者要花時間來確認那些是程序出現的錯誤，那些是由于單元測試更新滯后造成的錯誤。這樣就失去了單元測試的意義，同時又給大家增加了負擔。如此折騰多次以后，大家就會覺得維護單元測試是一件很費時費力的事。
|
