軟件開發(fā)習慣中一個細微更改都可能會對軟件質(zhì)量產(chǎn)生巨大改進。將單元測試合并到開發(fā)過程中，然后從長遠角度來看它可以節(jié)省多少時間和精力。本文通過使用代碼樣本說明了單元測試的種種好處，特別是使用 Ant 和 JUnit 帶來的各種方便。

　　測試是大型開發(fā)過程中的基本原則之一。在任何職業(yè)中，驗證都是一個重要部分。醫(yī)生要通過驗血來確診。波音公司在研制 777 的過程中對飛機的每個組件都進行了精心測試。為什么軟件開發(fā)應該例外呢？

　　以前，由于在應用程序中將 GUI 和商業(yè)邏輯緊密聯(lián)系在一起，這限制了創(chuàng)建自動測試的能力。當我們學會通過抽象層將商業(yè)邏輯從界面中分離出來時，各個單獨代碼模塊的自動測試替代了通過 GUI 進行的手工測試。

　　現(xiàn)在，集成開發(fā)環(huán)境 (IDE) 能在您輸入代碼的同時顯示錯誤，對于在類中快速查找方法具有智能探測功能，可以利用語法結(jié)構(gòu)生成彩色代碼，而且具有許多其它功能。因此，在編譯更改過的代碼之前，您已經(jīng)全盤考慮了將構(gòu)建的類，但您是否考慮過這樣的修改會破壞某些功能呢？

　　每個開發(fā)者都碰到過更改“臭蟲”。代碼修改過程可能會引入“臭蟲”，而如果通過用戶界面手工測試代碼的話，在編譯完成之前是不會發(fā)現(xiàn)它的。然后，您要花費幾天的時間追蹤由更改所引起的錯誤。近在我做的一個項目中，當我把后端數(shù)據(jù)庫由 Informix 更改到 Oracle 時遇到了這種情況。大部分更改都十分順利，但由于數(shù)據(jù)庫層或使用數(shù)據(jù)庫層的系統(tǒng)缺少單元測試，從而導致將大量時間花費在嘗試解決更改“臭蟲”上。我花了兩天的時間查到別人代碼中的一個數(shù)據(jù)庫語法更改。（當然，那個人仍是我的朋友。）

　　盡管測試有許多好處，但一般的程序員對測試都不太感興趣，開始時我也沒有。您聽到過多少次“它編譯了，所以它一定能用”這種言論？但“我思，故我在”這種原則并 不 適用于高質(zhì)量軟件。要鼓勵程序員測試他們的代碼，過程必須簡單無痛。

　　本文從某人學習用 Java語言編程時所寫的一個簡單的類開始。然后，我會告訴您我是如何為這個類編寫單元測試，以及在編寫完它以后又是如何將單元測試添加到構(gòu)建過程中的。后，我們將看到將“臭蟲”引入代碼時發(fā)生的情況。

　　從一個典型類開始
　　第一個典型的 Java 程序一般都包含一個打印 "Hello World" 的 main() 。在清單 1 中，我創(chuàng)建了一個 HelloWorld 對象的實例并調(diào)用 sayHello() 方法，該方法會打印這句習慣說法。

　　清單 1. 我的第一個 Java 應用程序 "Hello world"

/* * HelloWorld.java * My first java program */ class HelloWorld { /** * Print "Hello World" */ void sayHello() { System.out.println("Hello World"); } /** * Test */ public static void main( String[] args ) { HelloWorld world = new HelloWorld(); world.sayHello(); } }

　　main() 方法是我的測試。哦噢！我將代碼、文檔、測試和樣本代碼包含在了一個模塊中。保佑 Java！但隨著程序越變越大，這種開發(fā)方法很快開始顯現(xiàn)出了缺陷：

    混亂
    類接口越大， main() 越大。類可能僅僅因為正常的測試而變得非常龐大。
    代碼膨脹
    由于加入了測試，所以產(chǎn)品代碼比所需要的要大。但我不想交付測試，而只想交付產(chǎn)品。
    測試不可靠
    既然 main() 是代碼的一部分， main() 對其他開發(fā)者通過類接口無法訪問的私有成員和方法享有訪問權(quán)。出于這個原因，這種測試方法很容易出錯。
    很難自動測試
    要進行自動測試，我仍然必須創(chuàng)建另一程序來將參數(shù)傳遞給 main() 。

　　類開發(fā)
　　對我來說，類開發(fā)是從編寫 main() 方法開始的。我在編寫 main() 的時候定義類和類的用法，然后實現(xiàn)接口。它的一些明顯的缺陷也開始顯現(xiàn)出來。一個缺陷是我傳遞給 main() 來執(zhí)行測試的參數(shù)個數(shù)。其次， main() 本身在進行調(diào)用子方法、設(shè)置代碼等操作時變得很混亂。有時 main() 會比類實現(xiàn)的其余部分還要大。

　　更簡單的過程
我原來的做法有一些很明顯的缺陷。因此，讓我們看看有什么別的方法可以使問題簡化。我仍然通過接口設(shè)計代碼并給出應用示例，正如原來的 main() 一樣。不同的是我將代碼放到了另一個單獨的類中，而這個類恰好是我的“單元測試”。這種技術(shù)有以下幾點好處：

    設(shè)計類的一種機制
    因為是通過接口進行開發(fā)，所以不太可能利用類的內(nèi)部功能。但因為我是目標類的開發(fā)者，我有到其內(nèi)部工作的“窗口”，所以測試并不是個真正的黑箱。僅憑這一點足夠推斷出需要開發(fā)者本人在編寫目標類的同時負責測試的開發(fā)，而不是由其他任何人代勞。
    類用法的示例
    通過將示例從實現(xiàn)中分離出來，開發(fā)者可以更快地提高速度，而且再不用在源代碼上糾纏不清。這種分離還有助于防止開發(fā)者利用類的內(nèi)部功能，因為這些功能將來可能已經(jīng)不存在了。
    沒有類混亂的 main()
    我不再受到 main() 的限制了。以前我得將多個參數(shù)傳遞給 main() 來測試不同的配置�，F(xiàn)在我可以創(chuàng)建許多單獨的測試類，每一個都維護各自的設(shè)置代碼。

　　接下來我們將這個單獨的單元測試對象放入構(gòu)建過程中。這樣，我們可以提供自動確認過程的方法。

    確保所做的任何更改都不會對其他人產(chǎn)生不利影響。
    我們在進行源碼控制之前可以測試代碼，而無需等待匯編測試或在夜晚進行的構(gòu)建測試。這有助于盡早捕捉到“臭蟲”，從而降低產(chǎn)生高質(zhì)量代碼的成本。
    通過提供增量測試過程，我們提供了更好的實現(xiàn)過程。如同 IDE 幫助我們在輸入時捕捉到語法或編譯“臭蟲”一樣，增量單元測試也幫助我們在構(gòu)建時捕捉到代碼更改“臭蟲”。

　　使用 JUnit 自動化單元測試
　　要使測試自動化，您需要一個測試框架。您可以自己開發(fā)或購買，也可以使用某些開放源代碼工具，例如 JUnit。我選擇 JUnit 出于以下幾個原因：

    不需要編寫自己的框架。
    它是開放源代碼，因此不需要購買框架。
    開放源代碼社區(qū)中的其他開發(fā)者會使用它，因此可以找到許多示例。
    它可以讓我將測試代碼與產(chǎn)品代碼分開。
    它易于集成到我的構(gòu)建過程中。

　　測試布局
　　圖 1 顯示了使用樣本 TestSuite 的 JUnit TestSuite 布局。每個測試都由若干單獨的測試案例構(gòu)成。每個測試案例都是一個單獨的類，它擴展了 TestClass 類并包含了我的測試代碼，即那些曾在 main() 中出現(xiàn)的代碼。在該例中，我向 TestSuite 添加了兩個測試：一個是 SkeletonTest，我將它用作所有新類和 HelloWorld 類的起點。

圖 1. TestSuite 布局

　　測試類 HelloWorldTest.java