### JUnit測試框架 譯注：本段將使用英文詞：test-suite（測試套件）、test-case（測試用例）和test-fixture（測試裝備），期能直接對應圖4.1的JUnit結構組件，并有助于閱讀JUnit文檔。 我用的是JUnit，一個由Erich Gamma 和 Kent Beck [JUnit]開發的開放源碼測試框架。這個框架非常簡單，卻可讓你進行測試所需的所有重要事情。本章中我將運用這個測試框架來為一些IO classes幵發測試代碼。 首先我創建一個FileReaderTester 來測試文件讀取器。任何『包含測試代碼」 的class都必須衍生自測試框架所提供的TestCase class。這個框架運用Composite 模式[Gang of Four]，允許你將測試代碼聚集到suites（套件）中，如圖4.1。這些套件可以包含未加工的test-cases（測試用例），或其他test-suits（測試套件）。如此一來我就可以輕松地將一系列龐大的test-suits結合在一起，并自動運行它們。  圖4.1 測試框架的Composite結構 ~~~ class FileReaderTester extends TestCase { public FileReaderTester (String name) { super(name); } } ~~~ 這個新建的class必須有一個構造函數。完成之后我就可以開始添加測試代碼了。我的第一件工作是設置test fixture（測試裝備），那是指「用于測試的對象樣本」。由于我要讀一個文件，所以先備妥一個測試文件如下： ~~~ Bradman 99.94 52 80 10 6996 334 29 Pollock 60.97 23 41 4 2256 274 7Headley 60.83 22 40 4 2256 270* 10Sutcliffe 60.73 54 84 9 4555 194 16 ~~~ 進一步運用這個文件之前，我得先準備好test-fixture (測試裝備）。TestCase class 提供兩個函數專門針對此一用途：setUp()用來產生相關對象、tearDown()負責刪除它們。在TestCase class中這兩個函數都只有空殼。大多數時候你不需要操心test-fixture的拆除（垃圾回收器會扛起責任），但是在這里，以tearDown()關閉文件無疑是明智之舉： ~~~ class FileReaderTester... protected void setUp() { try { _input = new FileReader("data.txt"); } catch (FileNotFoundException e) { throw new RuntimeException ("unable to open test file"); } } protected void tearDown() { try { _input.close(); } catch (IOException e) { throw new RuntimeException ("error on closing test file"); } } ~~~ 現在我有了適當的test-fixture（測試裝備），可以開始編寫測試代碼了。首先要測試的是read()，我要讀取一些字符，然后檢查后續讀取的字符是否正確： ~~~ public void testRead() throws IOException { char ch = '&'; for (int i=0; i < 4; i++) ch = (char) _input.read(); assert('d' == ch); } ~~~ assert()扮演自動測試角色。如果assert()的參數值為ture，一切良好；否則我們就會收到錯誤通知。稍后我會讓你看看測試框架怎么向用戶報告錯誤消息。現在我要先介紹如何將測試過程運行起來。 第一步是產生一個test-suite（測試套件）。為達目的，請設計一個suite()如下： ~~~ class FileReaderTester... public static Test suite() { TestSuite suite= new TestSuite(); suite.addTest(new FileReaderTester("testRead")); return suite; } ~~~ 這個測試套件只含一個test-case（測試用例）對象，那個是FileReaderTester實體。創建test-case對象時，我傳給其構造函數一個字符串，這正是待測函數的名稱。這會創建出一個對象，用以測試被指定的函數。這個測試系通過Java反射機制（reflection）和對象系結在一起。你可以自由下載JUnit源碼，看看它究竟如何做到。至于我，我只把它當作一種魔法。 要將整個測試運行起來，還需要一個獨立的TestRunner class。TestRunner 有兩個版本，其中一個有漂亮的圖形用戶界面（GUI），另一個采用文字界面。我可以在main函數中調用「文字界面」版： ~~~ class FileReaderTester... public static void main (String[] args) { junit.textui.TestRunner.run (suite()); } ~~~ 這段代碼創建出一個TestRunner，并要它去測試FileReaderTester class。當我執行它，我看到： ~~~ . Time: 0.110 OK (1 tests) ~~~ 對于每個運行起來的測試，JUnit都會輸出一個句點，這樣你就可以直觀看到測試進展。它會告訴你整個測試用了多長時間。如果所有測試都沒有出錯，它就會說"OK"，并告訴你運行了多少筆測試。我可以運行上千筆測試，如果一切良好，我會看到那個"OK"。對于自我測試代碼來說，這個簡單的響應至關重要，沒有它我就不可能經常運行這些測試。有了這個簡單響應，你可以執行一大堆測試然后去吃個午飯（或幵個會），回來之后再看看測試結果。 TIP：頻繁地運行測試。每次編譯請把測試也考慮進去——每天至少執行毎個測試一次。 重構過程中，你可以只運行少數幾項測試，它們主要用來檢查當下正在開發或整理的代碼。是的，你可以只運行少數幾項測試，這樣肯定比較快，否則整個測試會減低你的開發速度，使你開始猶豫是否還要這樣下去。千萬別屈服于這種誘惑，否則 你一定會付出代價。 如果測試出錯，會發生什么事？為了展示這種情況，我故意放一只臭蟲進去： ~~~ public void testRead() throws IOException { char ch = '&'; for (int i=0; i < 4; i++) ch = (char) _input.read(); assert('2' == ch); //deliberate error } ~~~ 得到如下結果： ~~~ .F Time: 0.220 !!!FAILURES!!! Test Results: Run: 1 Failures: 1 Errors: 0 There was 1 failure: 1) FileReaderTester.testRead test.framework.AssertionFailedError ~~~ JUnit警告我測試失敗，并告訴我這項失敗具體發生在哪個測試身上。不過這個錯誤消息并不特別有用。我可以使用另一種形式的assert，讓錯誤消息更清楚些： ~~~ public void testRead() throws IOException { char ch = '&'; for (int i=0; i < 4; i++) ch = (char) _input.read(); assertEquals('m',ch); } ~~~ 你做的絕大多數都是對兩個值進行比較，檢驗它們是否相等，所以JUnit框架為你提供assertEquals()。這個函數很簡單：以equals()進行對象比較，以操作符==進行數值比較——我自己常忘記區分它們。這個函數也輸出更具意義的錯誤消息： ~~~ .F Time: 0.170 !!!FAILURES!!! Test Results: Run: 1 Failures: 1 Errors: 0 There was 1 failure: 1) FileReaderTester.testRead "expected:"m"but was:"d"" ~~~ 我應該提一下：編寫測試代碼時，我往往一開始先讓它們失敗。面對既有代碼，要不我就修改它（如果我能碰觸源碼的話），使它測試失敗，要不就在assertions中放一個錯誤期望值，造成測試失敗。之所以這么做，是為了向自己證明：測試機制的確可以運行，并且的確測試了它該測試的東西（這就是為什么上面兩種作法中我比較喜歡修改待測碼的原因）。這可能有些偏執，或許吧，但如果測試代碼所測的東西并非你想測的東西，你真的有可能被搞得迷迷糊糊。 除了捕捉「失敗」（failures，也就是assertions之結果為"false"），JUnit還可以捕捉「錯誤」（errors，意料外的異常）。如果我關閉input stream，然后試圖讀取它，就應該得到一個異常（exception）。我可以這樣測試： ~~~ public void testRead() throws IOException { char ch = '&'; _input.close(); for (int i=0; i < 4; i++) ch = (char) _input.read(); // will throw exception assertEquals('m',ch); } ~~~ 執行上述測試，我得到這樣的結果： ~~~ .E Time: 0.110 !!!FAILURES!!! Test Results: Run: 1 Failures: 0 Errors: 1 There was 1 error: 1) FileReaderTester.testRead java.io.IOException: Stream closed ~~~ 區分失敗（failures）和錯誤（errors）是很有用的，因為它們的出現形式不同，排除的過程也不同。 JUnit還包含一個很好的圖形用戶界面（GUI，見圖4.2）。如果所有測試都順利通過，窗口下端的進度桿（progress bar ）就呈綠色；如果有任何一個測試失敗，進度桿就呈紅色。你可以丟下這個不管，整個環境會自動將你在代碼所做的任何修改連接（links）進來。這是一個非常方便的測試環境。  圖4.2 JUnit的圖形用戶界面 **單元測試和功能測試** JUnit框架的用途是單元測試，所以我應該講講單元測試和功能測試之間的差異。 我一直掛在嘴上的其實是「單元測試」，編寫這些測試的目的是為了提高身為一個程序員的生產性能。至于讓質保部門開心，那只是附帶效果而已。單元測試是高度本地化（localized）的東西，每個test class只對單一package運作。它能夠測試其他packages的接口，除此之外它將假設其他一切正常。 功能測試就完全不同。它們用來保證軟件能夠正常運作。它們只負責向客戶提供質量保證，并不關心程序員的生產力。它們應該由一個喜歡尋找臭蟲的個別團隊來開發。這個團隊應該使用重量級工具和技術來幫助自己開發良好的功能測試。 一般而言，功能測試盡可能把整個系統當作一個黑箱。面對一個GUI待測系統，它 們通過GUI來操作那個系統。面對文件更新程序或數據庫更新程序，功能測試只觀察特定輸入所導致的數據變化。 一旦功能測試者或最終用戶找到軟件中的一只臭蟲，要除掉它至少需要做兩件事。 當然你必須修改代碼，才得以排除錯誤，但你還應該添加一個單元測試，讓它揭發這只臭蟲。事實上，每當收到臭蟲提報（bug report），我都首先編寫一個單元測試，使這只臭蟲浮現。如果需要縮小臭蟲出沒范圍，或如果出現其他相關失敗（failures），我就會編寫不只一個測試。我使用單元測試來幫助我盯住臭蟲，并確保我的單元測 試不會有類似的漏網之……呃……臭蟲。 TIP：每當你接獲臭蟲提報（bug report），請先撰寫一個單元測試來揭發這只臭蟲。 JUnit框架被設計用來編寫單元測試。功能測試往往以其他工具輔助進行，例如某些擁有GUI (圖形用戶界面）的測試工具，然而通常你還得撰寫一些與你的應用程序息息相關的測試工具，使能夠比單純使用GUI scripts （腳本語言）更輕松地管理 test cases (測試用例）。你也可以運用JUnit來執行功能測試，但這通常不是最有效的形式。當我要進行重構時，我倚賴程序員的好朋友：單元測試。