前面的一篇文章（單元測試－理論篇）討論了什么是單元測試、單元測試的優(yōu)點(diǎn)并列舉了很多不寫單元測試的借口。如果你同意我們的觀點(diǎn)，認(rèn)同單元測試確實(shí)是軟件開發(fā)中不可缺少的過程，那么我們就開始單元測試之旅吧！
一個(gè)比較最大值的函數(shù)
我們首先引入一個(gè)比較最大值的函數(shù)。我們傳入一個(gè)類型為int的數(shù)組參數(shù)，它將返回最大值的那個(gè)元素。代碼如下：
public class Largest {
public static int largest(int[] datas){
int max = 0;
for(int i = 0 ; i < datas.length ; i++){
if(max < datas[i]){
max = datas[i];
}
}
return max;
}
}
可是，如何寫我們的測試代碼呢？
直接在Largest類中添加一個(gè)main方法，要么重新寫一個(gè)可運(yùn)行的類來測試Largest。這樣的測試，同樣給我們帶來了很大的挑戰(zhàn)：
1、 驗(yàn)證困難。如何去驗(yàn)證代碼的行為和我們的期望一致呢？使用很多的if…else再加上＝＝或equals()來判斷？對(duì)異常的情況又如何處理呢？混亂的驗(yàn)證，很容易給我們的測試代碼帶來BUG，讓我們對(duì)自己的測試不夠自信。
2、 測試類無法管理。我們?nèi)绾沃庇^的得到測試運(yùn)行成功或失敗的消息?用原始的System.out.println()嗎？我們能一次運(yùn)行多個(gè)單元測試嗎？如果前面的測試運(yùn)行出現(xiàn)異常，后面的測試還能繼續(xù)運(yùn)行嗎？如果測試類很多，上百個(gè)甚至更多，我們能方便的由控制臺(tái)輸出測試結(jié)果嗎？
3、 無法統(tǒng)計(jì)測試代碼覆蓋情況。缺少統(tǒng)一的測試代碼編寫規(guī)范和約定，可讀性和維護(hù)性差。
不過，面對(duì)這些挑戰(zhàn)不用沮喪。單元測試框架已經(jīng)幫我們解決了這些問題，它提供了很多測試的基礎(chǔ)設(shè)施，讓我們能把更多的經(jīng)歷投入到測試代碼的編寫中來。
JUnit
JUnit最初是由Erich Gamma（GoF之一）和Kent Beck（xp和refactor的先驅(qū)之一）編寫的，它是一個(gè)開源的Java測試框架，用于編寫和運(yùn)行可重復(fù)的測試。
下面我們逐步介紹如何對(duì)Largest類測試：
一、 JUnit的安裝。如果你使用的開發(fā)工具是Eclipse，不用做任何安裝，它已經(jīng)提供了Junit的支持。否則，你需要去http://www.junit.org/ 下載Junit安裝包。安裝非常簡單，只要將junit.jar包設(shè)置到ClassPath中，讓你的Java代碼能夠找到它就可以了。
二、 編寫測試代碼。代碼如下：
public class LargestTest extends TestCase {
public void testLargest(){
int[] datas = {7,8,9};
assertEquals(9,Largest.largest(datas));
}
}
說明：
1、 測試類一般要繼承抽象類TestCase。它實(shí)現(xiàn)了各種測試方法，并提供了一個(gè)測試過程的架構(gòu)。
2、 測試代碼通過斷言（Assert）來判斷某個(gè)被測試函數(shù)是否正常工作。JUnit提供了很多斷言函數(shù)，用來確定：某個(gè)條件是否為真；兩個(gè)數(shù)據(jù)是否相等，或者不等，或者其它的一些情況。
3、 測試方法名以“test”開頭，這樣JUnit框架會(huì)自動(dòng)發(fā)現(xiàn)這是一個(gè)測試方法。
三、 運(yùn)行測試類。
運(yùn)行測試成功。
我們的單元測試這樣就算完成了嗎？不，上面的測試只能算是一次驗(yàn)證而已。我們給的數(shù)據(jù)中，最大值9是數(shù)組的最后一個(gè)元素，如果9是第一個(gè)元素它還正確嗎？如果數(shù)據(jù)是負(fù)數(shù)呢？等等。我們的求最大值函數(shù)有著很多的邊界情況需要單元測試來驗(yàn)證。
因此，我們?cè)趯憜卧獪y試之前，一定要對(duì)測試做一個(gè)周全的計(jì)劃，預(yù)先設(shè)置好要測試的內(nèi)容，可能發(fā)生錯(cuò)誤的邊界條件。
下面是對(duì)Largest做的測試計(jì)劃：
1、 數(shù)組元素的位置是否對(duì)最大值產(chǎn)生影響？
l [7,8,9] – 9
l [7,9,8] – 9
l [9,8,7] – 9
2、 如果有兩個(gè)相等的最大值，會(huì)出現(xiàn)什么情況呢？
l [7,9,8,9] – 9
3、如果數(shù)組中只有一個(gè)元素，結(jié)果會(huì)怎么樣？
l [1] - 1
4、 如果元素都是負(fù)數(shù)呢？
l [-7,-8,-9] - -7
完整的測試代碼應(yīng)該如下：
public class LargestTest extends TestCase {
public void testSimple(){
assertEquals(9,Largest.largest(new int[]{7,8,9}));
}
public void testOrder(){
assertEquals(9,Largest.largest(new int[]{7,9,8}));
assertEquals(9,Largest.largest(new int[]{9,8,7}));
}
public void testDups(){
assertEquals(9,Largest.largest(new int[]{7,9,8,9}));
}
public void testOne(){
assertEquals(1,Largest.largest(new int[]{1}));
}
public void testNegative(){
assertEquals(-7,Largest.largest(new int[]{-7,-8,-9}));
}
}
當(dāng)然，你可以寫完一個(gè)測試方法就立即來運(yùn)行它。這次并沒有那么幸運(yùn)了，在運(yùn)行最后一個(gè)測試方法testNegative()時(shí)出現(xiàn)了錯(cuò)誤：
junit.framework.AssertionFailedError: expected:<-7> but was:<0>
at test.junit.LargestTest.testNegative(LargestTest.java:24)
細(xì)心的你，也許在一開始就發(fā)現(xiàn)了Largest的這個(gè)Bug。原來我們的字段max初始化為0是不對(duì)的，應(yīng)該改為Integer.MIN_VALUE。
由此我們可以想到，使用單元測試確實(shí)可以盡早的發(fā)現(xiàn)隱藏的BUG，上一篇我們也說過，越早發(fā)現(xiàn)BUG就能節(jié)省更多的時(shí)間，降低更多的風(fēng)險(xiǎn)。
這是，我們的單元測試已經(jīng)完美結(jié)束了嗎？呵呵，也許你會(huì)想到，如果在largest()方法中傳入數(shù)組為空，又會(huì)怎么樣呢？這個(gè)問題留給我們的讀者思考吧。
寫到這里，算是入門結(jié)束了吧！關(guān)于JUnit的詳細(xì)介紹，網(wǎng)上有非常多的文章，去google你可以找到一大堆。下面我提供幾個(gè)不錯(cuò)的單元測試網(wǎng)站，希望能對(duì)你有所幫助：
51Testing-無憂軟件測試網(wǎng)：http://www.51testing.com/
測試時(shí)代：http://www.testage.net/
UML軟件工程組織－軟件測試：http://www.uml.org.cn/Test/test.asp
測試管理中心：http://www.testmanager.com.cn/
軟件工程專家網(wǎng)：http://www.51cmm.com/
開放軟件測試研究：http://www.opentest.net/