TestCase

需要提醒一下，在junit.framework.Assert類中定義了相當(dāng)多的assert方法，主要有assert()， assert()， assertEquals()， assertNull()， assertSame()， assertTrue()， fail()等方法。如果你需要比較自己定義的類，如Car。assert方法需要你覆蓋Object類的equals()方法，以比較兩個對象的不同。實(shí)踐表明:如果你覆蓋了Object類的equals()方法，好也覆蓋Object類的hashCode()方法。再進(jìn)一步，連帶Object類的toString()方法也一并覆蓋。這樣可以使測試結(jié)果更具可讀性。

當(dāng)你設(shè)置好了Fixture后，下一步是編寫所需的testXXX()方法。一定要保證testXXX()方法的public屬性，否則無法通過內(nèi)�。╮eflection）對該測試進(jìn)行調(diào)用。

每個擴(kuò)展的TestCase類（也是你編寫的測試類）會有多個testXXX()方法。一個testXXX()方法是一個測試。要想運(yùn)行這個測試，你必須定義如何運(yùn)行該測試。如果你有多個testXXX()方法，你要定義多次。JUnit支持兩種運(yùn)行單個測試的方法：靜態(tài)的和動態(tài)的方法。

靜態(tài)的方法是覆蓋TestCase類的runTest()方法，一般是采用內(nèi)部類的方式創(chuàng)建一個測試實(shí)例：
TestCase test01 = new testCar("test getWheels") {
public void runTest() {
testGetWheels();
}
}

采用靜態(tài)的方法要注意要給每個測試一個名字（這個名字可以任意起，但你肯定希望這個名字有某種意義），這樣你可以區(qū)分那個測試失敗了。

動態(tài)的方法是用內(nèi)省來實(shí)現(xiàn)runTest()以創(chuàng)建一個測試實(shí)例。這要求測試的名字是需要調(diào)用的測試方法的名字：
TestCase test01 = new testCar("testGetWheels");

JUnit會動態(tài)查找并調(diào)用指定的測試方法。動態(tài)的方法很簡潔，但如果你鍵入了錯誤的名字會得到一個令人奇怪的NoSuchMethodException異常。動態(tài)的方法和靜態(tài)的方法都很好，你可以按照自己的喜好來選擇。（先別著急選擇，后面還有一種更酷的方法等著你呢。）

TestSuite

一旦你創(chuàng)建了一些測試實(shí)例，下一步是要讓他們能一起運(yùn)行。我們必須定義一個TestSuite。在JUnit中，這要求你在TestCase類中定義一個靜態(tài)的suite()方法。suite()方法像main()方法一樣，JUnit用它來執(zhí)行測試。在suite()方法中，你將測試實(shí)例加到一個TestSuite對象中，并返回這個TestSuite對象。一個TestSuite對象可以運(yùn)行一組測試。TestSuite和TestCase都實(shí)現(xiàn)了Test接口（interface），而Test接口定義了運(yùn)行測試所需的方法。這允許你用TestCase和TestSuite的組合創(chuàng)建一個TestSuite。這是為什么我們前面說TestCase，TestSuite以及TestSuite組成了一個composite Pattern的原因。例子如下：
public static Test suite() {
TestSuite suite= new TestSuite();
suite.addTest(new testCar("testGetWheels"));
suite.addTest(new testCar("testGetSeats"));
return suite;
}

從JUnit 2.0開始，有一種更簡單的動態(tài)定義測試實(shí)例的方法。你只需將類傳遞給TestSuite，JUnit會根據(jù)測試方法名自動創(chuàng)建相應(yīng)的測試實(shí)例。所以你的測試方法好取名為testXXX()。例子如下：
public static Test suite() {
return new TestSuite(testCar.class);
}

從JUnit的設(shè)計(jì)我們可看出，JUnit不僅可用于單元測試，也可用于集成測試。關(guān)于如何用JUnit進(jìn)行集成測試請參考相關(guān)資料。

為了兼容性的考慮，下面列出使用靜態(tài)方法的例子：
public static Test suite() {
TestSuite suite= new TestSuite();
suite.addTest(
new testCar("getWheels") {
 protected void runTest() { testGetWheels(); }
}
);

suite.addTest(
new testCar("getSeats") {
 protected void runTest() { testGetSeats(); }
}
);
return suite;
}

TestRunner

有了TestSuite我們可以運(yùn)行這些測試了，JUnit提供了三種界面來運(yùn)行測試
[Text  UI] junit.textui.TestRunner
[AWT   UI] junit.awtui.TestRunner
[Swing UI] junit.swingui.TestRunner

我們前面已經(jīng)看過文本界面了，下面讓我們來看一看圖形界面：

界面很簡單，鍵入類名－testCar�；蛟趩�動UI的時(shí)候鍵入類名：
[Windows] d:>;java junit.swingui.TestRunner testCar
   [Unix] ％ java junit.swingui.TestRunner testCar

從圖形UI可以更好的運(yùn)行測試可查單測試結(jié)果。還有一個問題需要注意：如果JUnit報(bào)告了測試沒有成功，JUnit會區(qū)分失敗（failures）和錯誤（errors）。失敗是一個期望的被assert方法檢查到的結(jié)果。而錯誤則是意外的問題引起的，如ArrayIndexOutOfBoundsException。

由于TestRunner十分簡單，界面也比較直觀，故不多介紹。朋友們可自行參考相關(guān)資料。

JUnit佳實(shí)踐

Martin Fowler（又是這位高人）說過：“當(dāng)你試圖打印輸出一些信息或調(diào)試一個表達(dá)式時(shí)，寫一些測試代碼來替代那些傳統(tǒng)的方法。”一開始，你會發(fā)現(xiàn)你總是要創(chuàng)建一些新的Fixture，而且測試似乎使你的編程速度慢了下來。然而不久之后，你會發(fā)現(xiàn)你重復(fù)使用相同的Fixture，而且新的測試通常只涉及添加一個新的測試方法。

你可能會寫許多測試代碼，但你很快會發(fā)現(xiàn)你設(shè)想出的測試只有一小部分是真正有用的。你所需要的測試是那些會失敗的測試，即那些你認(rèn)為不會失敗的測試，或你認(rèn)為應(yīng)該失敗卻成功的測試。

我們前面提到過測試是一個不會中斷的過程。一旦你有了一個測試，你要一直確保其正常工作，以檢驗(yàn)?zāi)闼�加入的新的工作代碼。不要每隔幾天或后才運(yùn)行測試，每天你都應(yīng)該運(yùn)行一下測試代碼。這種投資很小，但可以確保你得到可以信賴的工作代碼。你的返工率降低了，你會有更多的時(shí)間編寫工作代碼。

不要認(rèn)為壓力大，不寫測試代碼。相反編寫測試代碼會使你的壓力逐漸減輕，應(yīng)為通過編寫測試代碼，你對類的行為有了確切的認(rèn)識。你會更快地編寫出有效率地工作代碼。下面是一些具體的編寫測試代碼的技巧或較好的實(shí)踐方法：

1. 不要用TestCase的構(gòu)造函數(shù)初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依賴或假定測試運(yùn)行的順序，因?yàn)镴Unit利用Vector保存測試方法。所以不同的平臺會按不同的順序從Vector中取出測試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨后的測試依賴于某些特定的交易數(shù)據(jù)，不要提交交易數(shù)據(jù)。簡單的會滾可以了。
4. 當(dāng)繼承一個測試類時(shí)，記得調(diào)用父類的setUp()和tearDown()方法。
5. 將測試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）
6. 測試類和測試方法應(yīng)該有一致的命名方案。如在工作類名前加上test從而形成測試類名。
7. 確保測試與時(shí)間無關(guān)，不要依賴使用過期的數(shù)據(jù)進(jìn)行測試。導(dǎo)致在隨后的維護(hù)過程中很難重現(xiàn)測試。
8. 如果你編寫的軟件面向國際市場，編寫測試時(shí)要考慮國際化的因素。不要僅用母語的Locale進(jìn)行測試。
9. 盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡潔。
10.測試要盡可能地小，執(zhí)行速度快。

事實(shí)上，JUnit還可用于集成測試，但我并沒涉及到，原因有兩個：一是因?yàn)闆]有單元測試，集成測試無從談起。我們接受測試地概念已經(jīng)很不容易了，如果再引入集成測試會更困難。二是我比較懶，希望將集成測試的任務(wù)交給測試人員去做。在JUnit的網(wǎng)站上有一些相關(guān)的文章，有空大家可以翻一翻。

JUnit與J2EE

如果大家仔細(xì)考慮一下的話，會發(fā)現(xiàn)，JUnit有自己的局限性，比如對圖形界面的測試，對servlet/JSP以及EJB的測試我們都沒有舉相關(guān)的例子。實(shí)際上，JUnit對于GUI界面，servlet/JSP，JavaBean以及EJB都有辦法測試。關(guān)于GUI的測試比較復(fù)雜，適合用一整篇文章來介紹。這里不多說了。

前面我們所做的測試實(shí)際上有一個隱含的環(huán)境，JVM我們的類需要這個JVM來執(zhí)行。而在J2EE框架中，servlet/JSP，EJB都要求有自己的運(yùn)行環(huán)境：Web Container和EJB Container。所以，要想對servlet/JSP，EJB進(jìn)行測試需要將其部署在相應(yīng)的Container中才能進(jìn)行測試。由于EJB不涉及UI的問題（除非EJB操作XML數(shù)據(jù)，此時(shí)的測試代碼比較難寫，有可能需要你比較兩棵DOM樹是否含有相同的內(nèi)容）只要部署上去之后可以運(yùn)行測試代碼了。此時(shí)setUp()方法顯得特別有用，你可以在setUp()方法中利用JNDI查找特定的EJB。而在testXXX()方法中調(diào)用并測試這些EJB的方法。

這里所指的JavaBean同樣沒有UI的問題，比如，我們用JavaBean來訪問數(shù)據(jù)庫，或用JavaBean來包裹EJB。如果這類JavaBean沒有用到Container的提供的服務(wù)，則可直接進(jìn)行測試，同我們前面所說的一般的類的測試方法一樣。如果這類JavaBean用到了Container的提供的服務(wù)，則需要將其部署在Container中才能進(jìn)行測試。方法與EJB類似。

對于servlet/JSP的測試則比較棘手，有人建議在測試代碼中構(gòu)造HttpRequest和HttpResponse，然后進(jìn)行比較，這要求開發(fā)人員對HTTP協(xié)議以及servlet/JSP的內(nèi)部實(shí)現(xiàn)有比較深的認(rèn)識。我認(rèn)為這招不太現(xiàn)實(shí)。也有人提出使用HttpUnit。由于我對Cactus和HttpUnit 了解不多，所以無法做出合適的建議。希望各位先知們能不吝賜教。

正是由于JUnit的開放性和簡單易行，才會引出這篇介紹文章。但技術(shù)總在不斷地更新，而且我對測試并沒有非常深入的理解；我可以將一個復(fù)雜的概念簡化成一句非常容易理解的話。但我的本意只是希望能降低開發(fā)人員步入測試領(lǐng)域的門檻，而不是要修改或重新定義一些概念。這一點(diǎn)是特別要強(qiáng)調(diào)的。后，如果有些兄弟姐妹能給我指出一些注意事項(xiàng)或我對某些問題的理解有誤，我會非常感激的。