軟件開發習慣中一個細微更改都可能會對軟件質量產生巨大改進。將單元測試合并到開發過程中，然后從長遠角度來看它可以節省多少時間和精力。本文通過使用代碼樣本說明了單元測試的種種好處，特別是使用 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() 。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
