以前曾經寫了一篇博文談如何推廣
單元測試，最近有朋友問我如下的問題，因此便又寫了本文，閱讀時請綜合原來的博文。
問題：
有開發人員認為進行單元測試會花費大量時間來編寫
測試用例，因此他們做單元測試的意愿比較低，請問有何好的建議進行單元測試的改進？
解答：
1、首先應該明確單元的含義。單元在面向對象的程序中指的是一個類，在結構化的方法中指的是一個函數。
2、其次應該明確單元測試的方法。單元測試的常用方法包括：
(1) 靜態檢查，即采用靜態代碼檢查的工具對程序進行內部邏輯的分析，以分析程序中可能的錯誤或壞味道。
(2) 動態測試，通過編寫單元測試程序，設計單元測試用例，測試每個函數或每個類的邏輯正確性。
3如果一個類或一個函數對其他的類或環境依賴性很強，需要編寫大量的樁程序或驅動程序，那恰恰說明了這個類或這個函數的設計有問題，違背了“低耦合”的基本設計原則，這也正式
敏捷方法中提倡的“測試驅動開發”的作用之一。
4、質量的投入產出也是一種平衡，需要在單元測試上投入到什么程度首先是公司的一個管理方針。如果每個單元都進行單元測試則測試代碼的規模和產品代碼的規模能夠達到1：1，也就是說編寫測試代碼的
工作量還是比較大的，但是也要看到單元測試的產出。在單元測試、集成測試、
系統測試中，單元測試是投入產出比最大的測試種類，即單元測試在單位時間內發現的缺陷個數大于集成與系統測試。原則上單元測試的投入最大，找到的缺陷最多，集成測試與系統測試依次遞減。
5、在實踐中推廣單元測試時可以采用如下的方法：
(1) 加大靜態檢查的力度。通過靜態檢查的工具快速地識別程序中的錯誤、警告、壞味道，公司可以規定對檢查出的哪些警告、壞味道必須進行修改，注意如果修改所有的警告、壞味道可能工作量比較大。靜態檢查是一種投入產出比很高的單元測試方法。在JAVA下可以采用check Style, Source monitor，PMD，Find Bugs，Jslink等。
(2) 通過測試策略的選擇減少測試程序的工作量。單元測試一般有三種策略：
策略一：自底向上的策略：先測底層的函數或類，再測上層的函數或類，此時只需要編寫驅動程序，不需要編寫樁程序。
策略二：自頂向下的策略：先測上層的函數或類，再測試底層的函數類，此時只需要編寫樁程序，不需要或很少需要編寫驅動程序。
策略三：混合策略：綜合上述的2種策略，需要綜合編寫樁程序與驅動程序。
如果被測的單元需要調用很多其他的單元，則可以采用自底向上的策略減少驅動程序的編寫量。如果被測的單元需要很多外圍的環境準備則可以采用自頂向下的策略。
(3) 在組織級可以規定執行單元測試的時機,比如：
i)系統中最核心的、最關鍵的功能模塊；
ii)算法復雜的功能模塊；
iii)出錯最多的功能模塊；
iv)客戶最常使用的功能模塊；
v)復用的底層代碼
根據Pareto定律，我們可以選擇少部分代碼執行單元測試。
6、單元測試的技術
(1) XUnit的工具
(2) 生成測試用例時可以采用如下的方法：
i）單元功能分析
ii）入口參數等價類分析
iii）入口參數邊界分析
iv）全程變量、共享數據的等價類與邊界分析
v）調用函數返回值的等價類與邊界分析
vi）覆蓋率分析
上述的方法要求的嚴格程度可以循序漸進,不能的嚴格程度需要投入的工作量不同。