這篇文章將向你介紹Junit，一個用來在項目中進行測試和調試的工具。在介紹完TDD(以測試驅動開發)理論后，將進一步講解怎樣在流行的Eclipse中建立你自己的JUnit測試。向你展示如何測試Hello World這樣簡單的程序。
許多書上都討論了自動測試，但是只有很少的著作注意到這么一個問題，那是怎樣把這些測試組織起來。隨著測試的增加，放置和調用這些測試卻變得更加麻煩。這將成為一個重要問題，以至于出現了TDD，極限編程(XP)使TDD得以普及。另外，你可以這樣理解TDD：通過測試來開發。
TDD的主要規范 :
在編寫程序代碼之前，與之對應的自動測試必須被寫好。甚至程序代碼并不存在，那也要看見一個失敗的測試結果。
在測試通過后，副本代碼必須被丟棄。
有一個具體步驟(可能指的是《Extreme Programming》)可以被任何一個程序員來參考，而不需要特殊的其他方法。在我們開始寫測試之前，這些步驟(章節)應該被首先閱讀――怎樣組織自動測試。
講解一下不同種類的測試：
單元測試：檢測模塊(也是類)的正確性。如果對象需要訪問外部的數據資源，例如數據庫，需要模擬一個mock objects，但在實際中真實數據與測試環境是不同的。
客戶測試：這是功能性、系統、和驗收測試。用來測試整體的系統特性。在XP中，這些測試由用戶編寫。
綜合測試：介于用戶測試和單元測試之間的橋梁。綜合測試幫助測試應用程序的交互性。一般情況下，mock objects不被用于綜合測試，它會增加測試時間。同樣，綜合測試經常依賴特殊的測試環境，例如數據庫送來的測試數據。綜合測試也需要用到外部類庫。例如為J2EE應用程序進行綜合測試的類庫Cactus。解釋這些測試超出了本文的范圍，需要更加詳細的信息請參考http://jakarta.apache.org/cactus/。
開發人員測試：這是用來讓開發人員檢驗自己代碼或新函數的。對于每一個開發人員，只要有可能，需要有更多的測試來檢驗代碼。組織這些測試和組織程序代碼一樣重要。
在以下章節，只要提到“測試”，那指的是開發人員測試。
我們幾乎準備好開始建立測試了，先應該為我們的測試選擇名字。你也許會說，“這不是問題：把‘Test’這個字放在類名前面，好了!”不會這么快!讓我來說一下這個步驟存在的問題：
在TDD中，被測試的類或者方法還不存在。
一個測試能夠覆蓋多個方法，甚至多個類，這是可能的。
以上只是一些普遍問題;還存在更多的問題。
