單元測試，測試什麼？

我們一直強調單元測試的重要性，但是有一個問題可能沒有認真去想過，測試是重要的，但是我們測試什麼呢？最近重讀《單元測試之道》，書中給出了答案：right-bicep

<b></b>

1.right——正确

很顯然，如果代碼運作的結果與你預期的不符合，那麼這段代碼肯定是有問題的。需要注意的是，right并意味着正确，因為正确隻是相對你所期望的結果而言，而對于使用者需求也許就是錯誤的。

<b>2.b——邊界條件</b>

尋找邊界條件是單元測試最有價值的工作之一，因為bug一般出現在邊界條件上，你常常需要考慮下面這些邊界條件：

1）完全僞造或者不一直的資料進行輸入

2）格式錯誤的資料，比如錯誤的url,email位址

3）空值或者不完整值，比如0,null

4)與常理相去甚遠的資料，比如人有10000歲？

5）如果要求傳入的是一個不允許重複資料的list，你傳入一個有重複資料的看看出現什麼情況

6）如果需要傳入的有序的集合，你傳入一個無序的看看結果

7）不按照次序地執行，比如未登入就嘗試操作某功能等

對于邊界條件，可以按照correct的順序去嘗試：

conformance——一緻性，值是否和預期的一樣

ordering——順序性，值是否如預期的那樣，有序或者無序

range——區間性，值是否處于合理的範圍内

reference——引用，值是否引用了代碼無法空值的外部資源

existence——值是否存在，為空？為0?不在集合内？

cardinatity——基數性，檢查你的函數能否正确地計數，不多不少

time——所有的事件的發生是否按照預期的順序，性能上滿足要求？

<b>3.inverse——檢查反向引用</b>

如果方法導緻某個結果，嘗試以另一個方法能否傳回最初的狀态？與原狀态是否符合預期？

<b>4。cross——交叉檢查</b>

通過不同的方法檢查一個方法産生的結果是否正确，比如用math.sqrt方法檢查自己編寫的求平方根的方法是否正确。另外的方式，以一種數量去檢查另一種數量，比如圖書館借出的書加上架上的書的總數是固定，可以用借出的書來檢查架上的書的數量是否正确。

<b>5.e——強制錯誤條件的産生</b>

一般我們所能想到的環境因素：

1）記憶體耗光

2）磁盤用滿

3）時鐘出問題

4）網絡不可用或者有問題

5）系統過載

6）調色闆顔色數目有限

7）顯示分辨率過高

再比如jdk版本差異，我就為這個問題頭痛過：）

<b>6.performance——性能</b>

每天或者每隔幾天運作一下一個粗糙簡單的性能測試，能夠保證你不會在給使用者示範的時候出現尴尬的場面。

盡管書上是講了這麼多測試這個、測試那個，我想真實的項目場景中應該根據需要采取特定的測試政策，比如你總不能對于一個單機應用需要考慮地震震斷海底光纜引發的問題。就我自己而言，因為項目組中似乎隻有我對junit等單元測試工具充滿興趣，有經驗的老程式員是自己寫一個帶main方法的test類進行測試，而更多的人根本就不知道單元測試或者知道也不感興趣，在沒有壓力的情況下，要求自己考慮這麼多的測試内容，難矣。今天試用了下nunit，感覺比junit難用多了，junit與eclipse的結合非常簡便。

文章轉自莊周夢蝶  ，原文釋出時間5.17