1、 2005 年 10 月 13 日J(rèn)Unit 是 Java 語(yǔ)言事實(shí)上的 標(biāo)準(zhǔn)單元測(cè)試庫(kù)。JUnit 4 是該庫(kù)三年以來(lái)最具里程碑意義的一次發(fā)布。它的新特性主要是通過(guò)采用 Java 5 中的標(biāo)記（annotation）而不是利用子類(lèi)、反射或命名機(jī)制來(lái)識(shí)別測(cè)試，從而簡(jiǎn)化測(cè)試。在本文中，執(zhí)著的代碼測(cè)試人員 Elliotte Harold 以 JUnit 4 為例，詳細(xì)介紹了如何在自己的工作中使用這個(gè)新框架。注意，本文假設(shè)讀者具有 JUnit 的使用經(jīng)驗(yàn)。JUnit 由 Kent Beck 和 Erich Gamma 開(kāi)發(fā)，幾乎毫無(wú)疑問(wèn)是迄今所開(kāi)發(fā)的最重要的第三方 Java 庫(kù)。正如 Ma

2、rtin Fowler 所說(shuō)，“在軟件開(kāi)發(fā)領(lǐng)域，從來(lái)就沒(méi)有如此少的代碼起到了如此重要的作用”。JUnit 引導(dǎo)并促進(jìn)了測(cè)試的盛行。由于 JUnit，Java 代碼變得更健壯，更可靠，bug 也比以前更少。JUnit（它本身的靈感來(lái)自 Smalltalk 的 SUnit）衍生了許多 xUnit 工具，將單元測(cè)試的優(yōu)勢(shì)應(yīng)用于各種語(yǔ)言。nUnit (.NET)、pyUnit (Python)、CppUnit (C+)、dUnit (Delphi) 以及其他工具，影響了各種平臺(tái)和語(yǔ)言上的程序員的測(cè)試工作。然而，JUnit 僅僅是一個(gè)工具而已。真正的優(yōu)勢(shì)來(lái)自于 JUnit 所采用的思想和技術(shù)，而不是框架

3、本身。單元測(cè)試、測(cè)試先行的編程和測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)并非都要在 JUnit 中實(shí)現(xiàn)，任何比較 GUI 的編程都必須用 Swing 來(lái)完成。JUnit 本身的最后一次更新差不多是三年以前了。盡管它被證明比大多數(shù)框架更健壯、更持久，但是也發(fā)現(xiàn)了 bug；而更重要的是，Java 不斷在發(fā)展。Java 語(yǔ)言現(xiàn)在支持泛型、枚舉、可變長(zhǎng)度參數(shù)列表和注釋?zhuān)@些特性為可重用的框架設(shè)計(jì)帶來(lái)了新的可能。JUnit 的停滯不前并沒(méi)有被那些想要廢棄它的程序員所打敗。挑戰(zhàn)者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。這些庫(kù)有一些可圈可點(diǎn)的特性

4、，但是都沒(méi)有達(dá)到 JUnit 的知名度和市場(chǎng)占有份額。它們都沒(méi)有在諸如 Ant、Maven 或 Eclipse 之類(lèi)的產(chǎn)品中具有廣泛的開(kāi)箱即用支持。所以 Beck 和 Gamma 著手開(kāi)發(fā)了一個(gè)新版本的 JUnit，它利用 Java 5 的新特性（尤其是注釋?zhuān)┑膬?yōu)勢(shì)，使得單元測(cè)試比起用最初的 JUnit 來(lái)說(shuō)更加簡(jiǎn)單。用 Beck 的話來(lái)說(shuō)，“JUnit 4 的主題是通過(guò)進(jìn)一步簡(jiǎn)化 JUnit，鼓勵(lì)更多的開(kāi)發(fā)人員編寫(xiě)更多的測(cè)試。”JUnit 4 盡管保持了與現(xiàn)有 JUnit 3.8 測(cè)試套件的向后兼容，但是它仍然承諾是自 JUnit 1.0 以來(lái) Java 單元測(cè)試方面最重大的改進(jìn)。注意：該框

5、架的改進(jìn)是相當(dāng)前沿的。盡管 JUnit 4 的大輪廓很清晰，但是其細(xì)節(jié)仍然可以改變。這意味著本文是對(duì) JUnit 4 搶先看，而不是它的最終效果。測(cè)試方法以前所有版本的 JUnit 都使用命名約定和反射來(lái)定位測(cè)試。例如，下面的代碼測(cè)試 1+1 等于 2：import junit.framework.TestCase;public class AdditionTest extends TestCase private int x = 1; private int y = 1; public void testAddition() int z = x + y; assertEquals(2, z)

6、; 而在 JUnit 4 中，測(cè)試是由 Test 注釋來(lái)識(shí)別的，如下所示：import org.junit.Test;import junit.framework.TestCase;public class AdditionTest extends TestCase private int x = 1; private int y = 1; Test public void testAddition() int z = x + y; assertEquals(2, z); 使用注釋的優(yōu)點(diǎn)是不再需要將所有的方法命名為 testFoo()、testBar()，等等。例如，下面的方法也可以工作：im

7、port org.junit.Test;import junit.framework.TestCase;public class AdditionTest extends TestCase private int x = 1; private int y = 1; Test public void additionTest() int z = x + y; assertEquals(2, z); 下面這個(gè)方法也同樣能夠工作：import org.junit.Test;import junit.framework.TestCase;public class AdditionTest extend

8、s TestCase private int x = 1; private int y = 1; Test public void addition() int z = x + y; assertEquals(2, z); 這允許您遵循最適合您的應(yīng)用程序的命名約定。例如，我介紹的一些例子采用的約定是，測(cè)試類(lèi)對(duì)其測(cè)試方法使用與被測(cè)試的類(lèi)相同的名稱(chēng)。例如，List.contains() 由 ListTest.contains() 測(cè)試，List.add() 由 ListTest.addAll() 測(cè)試，等等。TestCase 類(lèi)仍然可以工作，但是您不再需要擴(kuò)展它了。只要您用 Test 來(lái)注釋測(cè)試方

9、法，就可以將測(cè)試方法放到任何類(lèi)中。但是您需要導(dǎo)入 junit.Assert 類(lèi)以訪問(wèn)各種 assert 方法，如下所示：import org.junit.Assert;public class AdditionTest private int x = 1; private int y = 1; Test public void addition() int z = x + y; Assert.assertEquals(2, z); 您也可以使用 JDK 5 中新特性（static import），使得與以前版本一樣簡(jiǎn)單：import static org.junit.Assert.assert

10、Equals;public class AdditionTest private int x = 1; private int y = 1; Test public void addition() int z = x + y; assertEquals(2, z); 這種方法使得測(cè)試受保護(hù)的方法非常容易，因?yàn)闇y(cè)試案例類(lèi)現(xiàn)在可以擴(kuò)展包含受保護(hù)方法的類(lèi)了。 SetUp 和 TearDownJUnit 3 測(cè)試運(yùn)行程序（test runner）會(huì)在運(yùn)行每個(gè)測(cè)試之前自動(dòng)調(diào)用 setUp() 方法。該方法一般會(huì)初始化字段，打開(kāi)日志記錄，重置環(huán)境變量，等等。例如，下面是摘自 XOM 的 XSLTransf

11、ormTest 中的 setUp() 方法：protected void setUp() System.setErr(new PrintStream(new ByteArrayOutputStream(); inputDir = new File("data"); inputDir = new File(inputDir, "xslt"); inputDir = new File(inputDir, "input"); 在 JUnit 4 中，您仍然可以在每個(gè)測(cè)試方法運(yùn)行之前初始化字段和配置環(huán)境。然而，完成這些操作的方法不再需要叫做

12、setUp()，只要用 Before 注釋來(lái)指示即可，如下所示： Before protected void initialize() System.setErr(new PrintStream(new ByteArrayOutputStream(); inputDir = new File("data"); inputDir = new File(inputDir, "xslt"); inputDir = new File(inputDir, "input"); 甚至可以用 Before 來(lái)注釋多個(gè)方法，這些方法都在每個(gè)測(cè)試之前運(yùn)行

13、： Before protected void findTestDataDirectory() inputDir = new File("data"); inputDir = new File(inputDir, "xslt"); inputDir = new File(inputDir, "input"); Before protected void redirectStderr() System.setErr(new PrintStream(new ByteArrayOutputStream();清除方法與此類(lèi)似。在 JUnit

14、3 中，您使用 tearDown() 方法，該方法類(lèi)似于我在 XOM 中為消耗大量?jī)?nèi)存的測(cè)試所使用的方法：protected void tearDown() doc = null; System.gc(); 對(duì)于 JUnit 4，我可以給它取一個(gè)更自然的名稱(chēng)，并用 After 注釋它： After protected void disposeDocument() doc = null; System.gc(); 與 Before 一樣，也可以用 After 來(lái)注釋多個(gè)清除方法，這些方法都在每個(gè)測(cè)試之后運(yùn)行。最后，您不再需要在超類(lèi)中顯式調(diào)用初始化和清除方法，只要它們不被覆蓋即可，測(cè)試運(yùn)行程序?qū)⒏?/p>

15、據(jù)需要自動(dòng)為您調(diào)用這些方法。超類(lèi)中的 Before 方法在子類(lèi)中的 Before 方法之前被調(diào)用（這反映了構(gòu)造函數(shù)調(diào)用的順序）。After 方法以反方向運(yùn)行：子類(lèi)中的方法在超類(lèi)中的方法之前被調(diào)用。否則，多個(gè) Before 或 After 方法的相對(duì)順序就得不到保證。套件范圍的初始化JUnit 4 也引入了一個(gè) JUnit 3 中沒(méi)有的新特性：類(lèi)范圍的 setUp() 和 tearDown() 方法。任何用 BeforeClass 注釋的方法都將在該類(lèi)中的測(cè)試方法運(yùn)行之前剛好運(yùn)行一次，而任何用 AfterClass 注釋的方法都將在該類(lèi)中的所有測(cè)試都運(yùn)行之后剛好運(yùn)行一次。例如，假設(shè)類(lèi)中的每個(gè)測(cè)試

16、都使用一個(gè)數(shù)據(jù)庫(kù)連接、一個(gè)網(wǎng)絡(luò)連接、一個(gè)非常大的數(shù)據(jù)結(jié)構(gòu)，或者還有一些對(duì)于初始化和事情安排來(lái)說(shuō)比較昂貴的其他資源。不要在每個(gè)測(cè)試之前都重新創(chuàng)建它，您可以創(chuàng)建它一次，并還原它一次。該方法將使得有些測(cè)試案例運(yùn)行起來(lái)快得多。例如，當(dāng)我測(cè)試調(diào)用第三方庫(kù)的代碼中的錯(cuò)誤處理時(shí)，我通常喜歡在測(cè)試開(kāi)始之前重定向 System.err，以便輸出不被預(yù)期的錯(cuò)誤消息打亂。然后我在測(cè)試結(jié)束后還原它，如下所示：/ This class tests a lot of error conditions, which/ Xalan annoyingly logs to System.err. This hides Syste

17、m.err / before each test and restores it after each test.private PrintStream systemErr; BeforeClass protected void redirectStderr() systemErr = System.err; / Hold on to the original value System.setErr(new PrintStream(new ByteArrayOutputStream(); AfterClass protected void tearDown() / restore the or

18、iginal value System.setErr(systemErr);沒(méi)有必要在每個(gè)測(cè)試之前和之后都這樣做。但是一定要小心對(duì)待這個(gè)特性。它有可能會(huì)違反測(cè)試的獨(dú)立性，并引入非預(yù)期的混亂。如果一個(gè)測(cè)試在某種程度上改變了 BeforeClass 所初始化的一個(gè)對(duì)象，那么它有可能會(huì)影響其他測(cè)試的結(jié)果。它有可能在測(cè)試套件中引入順序依賴(lài)，并隱藏 bug。與任何優(yōu)化一樣，只在剖析和基準(zhǔn)測(cè)試證明您具有實(shí)際的問(wèn)題之后才實(shí)現(xiàn)這一點(diǎn)。這就是說(shuō)，我看到了不止一個(gè)測(cè)試套件運(yùn)行時(shí)間如此之長(zhǎng)，以至不能像它所需要的那樣經(jīng)常運(yùn)行，尤其是那些需要建立很多網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)連接的測(cè)試。（例如，LimeWire 測(cè)試套件運(yùn)行時(shí)間超過(guò)

19、兩小時(shí)。）要加快這些測(cè)試套件，以便程序員可以更加經(jīng)常地運(yùn)行它們，您可以做的就是減少 bug。測(cè)試異常異常測(cè)試是 JUnit 4 中的最大改進(jìn)。舊式的異常測(cè)試是在拋出異常的代碼中放入 try 塊，然后在 try 塊的末尾加入一個(gè) fail() 語(yǔ)句。例如，該方法測(cè)試被零除拋出一個(gè) ArithmeticException：public void testDivisionByZero() try int n = 2 / 0; fail("Divided by zero!"); catch (ArithmeticException success) assertNotNull(su

20、ccess.getMessage(); 該方法不僅難看，而且試圖挑戰(zhàn)代碼覆蓋工具，因?yàn)椴还軠y(cè)試是通過(guò)還是失敗，總有一些代碼不被執(zhí)行。在 JUnit 4 中，您現(xiàn)在可以編寫(xiě)拋出異常的代碼，并使用注釋來(lái)聲明該異常是預(yù)期的： Test(expected=ArithmeticException.class) public void divideByZero() int n = 2 / 0;如果該異常沒(méi)有拋出（或者拋出了一個(gè)不同的異常），那么測(cè)試就將失敗。但是如果您想要測(cè)試異常的詳細(xì)消息或其他屬性，則仍然需要使用舊式的 try-catch 樣式。被忽略的測(cè)試也許您有一個(gè)測(cè)試運(yùn)行的時(shí)間非常地長(zhǎng)。不是說(shuō)這個(gè)

21、測(cè)試應(yīng)該運(yùn)行得更快，而是說(shuō)它所做的工作從根本上比較復(fù)雜或緩慢。需要訪問(wèn)遠(yuǎn)程網(wǎng)絡(luò)服務(wù)器的測(cè)試通常都屬于這一類(lèi)。如果您不在做可能會(huì)中斷該類(lèi)測(cè)試的事情，那么您可能想要跳過(guò)運(yùn)行時(shí)間長(zhǎng)的測(cè)試方法，以縮短編譯-測(cè)試-調(diào)試周期?；蛘咭苍S是一個(gè)因?yàn)槌瞿目刂品秶脑蚨〉臏y(cè)試。例如，W3C XInclude 測(cè)試套件測(cè)試 Java 還不支持的一些 Unicode 編碼的自動(dòng)識(shí)別。不必老是被迫盯住那些紅色波浪線，這類(lèi)測(cè)試可以被注釋為 Ignore，如下所示：/ Java doesn't yet support / the UTF-32BE and UTF32LE encodings Ignore

22、public void testUTF32BE() throws ParsingException, IOException, XIncludeException File input = new File( "data/xinclude/input/UTF32BE.xml" ); Document doc = builder.build(input); Document result = XIncluder.resolve(doc); Document expectedResult = builder.build( new File(outputDir, "UT

23、F32BE.xml") ); assertEquals(expectedResult, result); 測(cè)試運(yùn)行程序?qū)⒉贿\(yùn)行這些測(cè)試，但是它會(huì)指出這些測(cè)試被跳過(guò)了。例如，當(dāng)使用文本界面時(shí)，會(huì)輸出一個(gè)“I”（代表 ignore），而不是為通過(guò)的測(cè)試輸出所經(jīng)歷的時(shí)間，也不是為失敗的測(cè)試輸出“E”：$ java -classpath .:junit.jar org.junit.runner.JUnitCore nu.xom.tests.XIncludeTestJUnit version 4.0rc1.I.Time: 1.149OK (7 tests)但是一定要小心。最初編寫(xiě)這些測(cè)試可能有

24、一定的原因。如果永遠(yuǎn)忽略這些測(cè)試，那么它們期望測(cè)試的代碼可能會(huì)中斷，并且這樣的中斷可能不能被檢測(cè)到。忽略測(cè)試只是一個(gè)權(quán)宜之計(jì)，不是任何問(wèn)題的真正解決方案。 時(shí)間測(cè)試測(cè)試性能是單元測(cè)試最為痛苦的方面之一。JUnit 4 沒(méi)有完全解決這個(gè)問(wèn)題，但是它對(duì)這個(gè)問(wèn)題有所幫助。測(cè)試可以用一個(gè)超時(shí)參數(shù)來(lái)注釋。如果測(cè)試運(yùn)行的時(shí)間超過(guò)指定的毫秒數(shù)，則測(cè)試失敗。例如，如果測(cè)試花費(fèi)超過(guò)半秒時(shí)間去查找以前設(shè)置的一個(gè)文檔中的所有元素，那么該測(cè)試失敗：Test(timeout=500) public void retrieveAllElementsInDocument() doc.query("/*"

25、); 除了簡(jiǎn)單的基準(zhǔn)測(cè)試之外，時(shí)間測(cè)試也對(duì)網(wǎng)絡(luò)測(cè)試很有用。在一個(gè)測(cè)試試圖連接到的遠(yuǎn)程主機(jī)或數(shù)據(jù)庫(kù)宕機(jī)或變慢時(shí)，您可以忽略該測(cè)試，以便不阻塞所有其他的測(cè)試。好的測(cè)試套件執(zhí)行得足夠快，以至程序員可以在每個(gè)測(cè)試發(fā)生重大變化之后運(yùn)行這些測(cè)試，有可能一天運(yùn)行幾十次。設(shè)置一個(gè)超時(shí)使得這一點(diǎn)更加可行。例如，如果解析 /xml 花費(fèi)了超過(guò) 2 秒，那么下面的測(cè)試就會(huì)超時(shí)：Test(timeout=2000) public void remoteBaseRelativeResolutionWithDirectory() throws IOException, Parsi

26、ngException builder.build("/xml"); 新的斷言JUnit 4 為比較數(shù)組添加了兩個(gè) assert() 方法：public static void assertEquals(Object expected, Object actual)public static void assertEquals(String message, Object expected, Object actual)這兩個(gè)方法以最直接的方式比較數(shù)組：如果數(shù)組長(zhǎng)度相同，且每個(gè)對(duì)應(yīng)的元素相同，則兩個(gè)數(shù)組相等，否則不相等。數(shù)組為空的情

27、況也作了考慮。 需要補(bǔ)充的地方JUnit 4 基本上是一個(gè)新框架，而不是舊框架的升級(jí)版本。JUnit 3 開(kāi)發(fā)人員可能會(huì)找到一些原來(lái)沒(méi)有的特性。 最明顯的刪節(jié)就是 GUI 測(cè)試運(yùn)行程序。如果您想在測(cè)試通過(guò)時(shí)看到賞心悅目的綠色波浪線，或者在測(cè)試失敗時(shí)看到令人焦慮的紅色波浪線，那么您需要一個(gè)具有集成 JUnit 支持的 IDE，比如 Eclipse。不管是 Swing 還是 AWT 測(cè)試運(yùn)行程序都不會(huì)被升級(jí)或捆綁到 JUnit 4 中。 下一個(gè)驚喜是，失?。╝ssert 方法檢測(cè)到的預(yù)期的錯(cuò)誤）與錯(cuò)誤（異常指出的非預(yù)期的錯(cuò)誤）之間不再有任何差別。盡管 JUnit 3 測(cè)試運(yùn)行程序仍然可以區(qū)別這些情

28、況，而 JUnit 4 運(yùn)行程序?qū)⒉辉倌軌騾^(qū)分。 最后，JUnit 4 沒(méi)有 suite() 方法，這些方法用于從多個(gè)測(cè)試類(lèi)構(gòu)建一個(gè)測(cè)試套件。相反，可變長(zhǎng)參數(shù)列表用于允許將不確定數(shù)量的測(cè)試傳遞給測(cè)試運(yùn)行程序。 我對(duì)消除了 GUI 測(cè)試運(yùn)行程序并不感到太高興，但是其他更改似乎有可能增加 JUnit 的簡(jiǎn)單性。只要考慮有多少文檔和 FAQ 當(dāng)前專(zhuān)門(mén)用于解釋這幾點(diǎn)，然后考慮對(duì)于 JUnit 4，您不再需要解釋這幾點(diǎn)了。 編譯和運(yùn)行 JUnit 4當(dāng)前，還沒(méi)有 JUnit 4 的庫(kù)版本。如果您想要體驗(yàn)新的版本，那么您需要從 SourceForge 上的 CVS 知識(shí)庫(kù)獲取它。分支（branch）是“Version4”（參見(jiàn) 參考資料）。注意，很多的文檔沒(méi)有升級(jí)，仍然是指以舊式的 3.x 方式做事。Java 5 對(duì)于編譯 JUnit 4 是必需的，因?yàn)?J