軟件開發習慣中一個細微更改都可能會對軟件質量產生巨大改進。將單元測試合并到開發過程中，然后從長遠角度來看它可以節省多少時間和精力。本文通過使用代碼樣本說明了單元測試的種種好處，特別是使用 Ant 和 JUnit 帶來的各種方便。
測試是大型開發過程中的基本原則之一。在任何職業中，驗證都是一個重要部分。醫生要通過驗血來確診。波音公司在研制 777 的過程中對飛機的每個組件都進行了精心測試。為什么軟件開發應該例外呢？
以前，由于在應用程序中將 GUI 和商業邏輯緊密聯系在一起，這限制了創建自動測試的能力。當我們學會通過抽象層將商業邏輯從界面中分離出來時，各個單獨代碼模塊的自動測試替代了通過 GUI 進行的手工測試。
現在，集成開發環境 (IDE) 能在您輸入代碼的同時顯示錯誤，對于在類中快速查找方法具有智能探測功能，可以利用語法結構生成彩色代碼，而且具有許多其它功能。因此，在編譯更改過的代碼之前，您已經全盤考慮了將構建的類，但您是否考慮過這樣的修改會破壞某些功能呢？
每個開發者都碰到過更改“臭蟲”。代碼修改過程可能會引入“臭蟲”，而如果通過用戶界面手工測試代碼的話，在編譯完成之前是不會發現它的。然后，您要花費幾天的時間追蹤由更改所引起的錯誤。近在我做的一個項目中，當我把后端數據庫由 Informix 更改到 Oracle 時遇到了這種情況。大部分更改都十分順利，但由于數據庫層或使用數據庫層的系統缺少單元測試，從而導致將大量時間花費在嘗試解決更改“臭蟲”上。我花了兩天的時間查到別人代碼中的一個數據庫語法更改。（當然，那個人仍是我的朋友。）
盡管測試有許多好處，但一般的程序員對測試都不太感興趣，開始時我也沒有。您聽到過多少次“它編譯了，所以它一定能用”這種言論？但“我思，故我在”這種原則并 不 適用于高質量軟件。要鼓勵程序員測試他們的代碼，過程必須簡單無痛。
本文從某人學習用 Java語言編程時所寫的一個簡單的類開始。然后，我會告訴您我是如何為這個類編寫單元測試，以及在編寫完它以后又是如何將單元測試添加到構建過程中的。后，我們將看到將“臭蟲”引入代碼時發生的情況。
從一個典型類開始
第一個典型的 Java 程序一般都包含一個打印 "Hello World" 的 main() 。在清單 1 中，我創建了一個 HelloWorld 對象的實例并調用 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！但隨著程序越變越大，這種開發方法很快開始顯現出了缺陷：
混亂
類接口越大， main() 越大。類可能僅僅因為正常的測試而變得非常龐大。
代碼膨脹
由于加入了測試，所以產品代碼比所需要的要大。但我不想交付測試，而只想交付產品。
測試不可靠
既然 main() 是代碼的一部分， main() 對其他開發者通過類接口無法訪問的私有成員和方法享有訪問權。出于這個原因，這種測試方法很容易出錯。
很難自動測試
要進行自動測試，我仍然必須創建另一程序來將參數傳遞給 main() 。
類開發
對我來說，類開發是從編寫 main() 方法開始的。我在編寫 main() 的時候定義類和類的用法，然后實現接口。它的一些明顯的缺陷也開始顯現出來。一個缺陷是我傳遞給 main() 來執行測試的參數個數。其次， main() 本身在進行調用子方法、設置代碼等操作時變得很混亂。有時 main() 會比類實現的其余部分還要大。
更簡單的過程
我原來的做法有一些很明顯的缺陷。因此，讓我們看看有什么別的方法可以使問題簡化。我仍然通過接口設計代碼并給出應用示例，正如原來的 main() 一樣。不同的是我將代碼放到了另一個單獨的類中，而這個類恰好是我的“單元測試”。這種技術有以下幾點好處：
設計類的一種機制
因為是通過接口進行開發，所以不太可能利用類的內部功能。但因為我是目標類的開發者，我有到其內部工作的“窗口”，所以測試并不是個真正的黑箱。僅憑這一點足夠推斷出需要開發者本人在編寫目標類的同時負責測試的開發，而不是由其他任何人代勞。
類用法的示例
通過將示例從實現中分離出來，開發者可以更快地提高速度，而且再不用在源代碼上糾纏不清。這種分離還有助于防止開發者利用類的內部功能，因為這些功能將來可能已經不存在了。
沒有類混亂的 main()
我不再受到 main() 的限制了。以前我得將多個參數傳遞給 main() 來測試不同的配置。現在我可以創建許多單獨的測試類，每一個都維護各自的設置代碼。
接下來我們將這個單獨的單元測試對象放入構建過程中。這樣，我們可以提供自動確認過程的方法。
確保所做的任何更改都不會對其他人產生不利影響。
我們在進行源碼控制之前可以測試代碼，而無需等待匯編測試或在夜晚進行的構建測試。這有助于盡早捕捉到“臭蟲”，從而降低產生高質量代碼的成本。
通過提供增量測試過程，我們提供了更好的實現過程。如同 IDE 幫助我們在輸入時捕捉到語法或編譯“臭蟲”一樣，增量單元測試也幫助我們在構建時捕捉到代碼更改“臭蟲”。
使用 JUnit 自動化單元測試
要使測試自動化，您需要一個測試框架。您可以自己開發或購買，也可以使用某些開放源代碼工具，例如 JUnit。我選擇 JUnit 出于以下幾個原因：
不需要編寫自己的框架。
它是開放源代碼，因此不需要購買框架。
開放源代碼社區中的其他開發者會使用它，因此可以找到許多示例。
它可以讓我將測試代碼與產品代碼分開。
它易于集成到我的構建過程中。
測試布局
圖 1 顯示了使用樣本 TestSuite 的 JUnit TestSuite 布局。每個測試都由若干單獨的測試案例構成。每個測試案例都是一個單獨的類，它擴展了 TestClass 類并包含了我的測試代碼，即那些曾在 main() 中出現的代碼。在該例中，我向 TestSuite 添加了兩個測試：一個是 SkeletonTest，我將它用作所有新類和 HelloWorld 類的起點。
圖 1. TestSuite 布局
測試類 HelloWorldTest.java
