類開發
對我來說，類開發是從編寫 main() 方法開始的。我在編寫 main() 的時候就定義類和類的用法，然后實現接口。它的一些明顯的缺陷也開始顯現出來。一個缺陷是我傳遞給 main() 來執行測試的參數個數。其次， main() 本身在進行調用子方法、設置代碼等操作時變得很混亂。有時 main() 會比類實現的其余部分還要大。
更簡單的過程
我原來的做法有一些很明顯的缺陷。因此，讓我們看看有什么別的方法可以使問題簡化。我仍然通過接口設計代碼并給出應用示例，正如原來的 main() 一樣。不同的是我將代碼放到了另一個單獨的類中，而這個類恰好是我的“單元測試”。這種技術有以下幾點好處：
設計類的一種機制
因為是通過接口進行開發，所以不太可能利用類的內部功能。但因為我是目標類的開發者，我有到其內部工作的“窗口”，所以測試并不是個真正的黑箱。僅憑這一點就足夠推斷出需要開發者本人在編寫目標類的同時負責測試的開發，而不是由其他任何人代勞。
類用法的示例
通過將示例從實現中分離出來，開發者可以更快地提高速度，而且再不用在源代碼上糾纏不清。這種分離還有助于防止開發者利用類的內部功能，因為這些功能將來可能已經不存在了。
沒有類混亂的 main()
我不再受到 main() 的限制了。以前我得將多個參數傳遞給 main() 來測試不同的配置�，F在我可以創建許多單獨的測試類，每一個都維護各自的設置代碼。
接下來我們將這個單獨的單元測試對象放入構建過程中。這樣，我們就可以提供自動確認過程的方法。
確保所做的任何更改都不會對其他人產生不利影響。
我們在進行源碼控制之前就可以測試代碼，而無需等待匯編測試或在夜晚進行的構建測試。這有助于盡早捕捉到“臭蟲”，從而降低產生高質量代碼的成本。
通過提供增量測試過程，我們提供了更好的實現過程。如同 IDE 幫助我們在輸入時捕捉到語法或編譯“臭蟲”一樣，增量單元測試也幫助我們在構建時捕捉到代碼更改“臭蟲”。
使用 JUnit 自動化單元測試
要使測試自動化，您需要一個測試框架。您可以自己開發或購買，也可以使用某些開放源代碼工具，例如 JUnit。我選擇 JUnit 出于以下幾個原因：
不需要編寫自己的框架。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
