Junit是對程序代碼進行單元測試的一種Java框架。通過每次修改程序之后測試代碼，程序員可以保證代碼的少量變動不會破壞整個系統(tǒng)。要不是有Junit這樣的自動化測試工具，代碼的反復測試簡直會把人累死而且還可能不準確�，F在好了，測試過程可以頻繁的進行而且還是自動的，所以你可以令程序錯誤減低到少。它寫的是單元測試（Unit Test）：軟件工程里的白盒測試，是測試某個類的某個方法的功能，XP中推崇的test first design是基于以上技術的。

    假如你要寫一段代碼：

    1：先用Junit寫測試，然后再寫代碼。

    2：寫完代碼，運行測試，測試失敗。

    3：修改代碼，運行測試，直到測試成功。

    假如以后對程序進行修改，優(yōu)化（refactoring），只要再運行測試代碼，假如所有的測試都成功，則代碼修改完成。

    Java下的team開發(fā)，一般采用cvs（版本控制），ant（項目治理），Junit（單元測試）的模式。

    先寫測試，再寫代碼的好處：

    從技術上強制你先考慮一個類的功能，也是這個類提供給外部的借口，而不至于太早陷入它的細節(jié)。這是面向對象提倡的一種設計原則。好的測試其實是一個好的文檔，這個類使用者往往可以通過查看這個類的測試代碼了解它的功能。一般的，假如你拿到別人的程序，對他寫的測試解讀是了解程序工程的好的方法。xp原則是make it simple，不是很推薦另外的文檔，因為項目在開發(fā)過程中往往處于變動中，假如在早期寫文檔，以后代碼變動還得的同步文檔，多了一個工作，而且由于項目時間緊，往往文檔寫的不全或者與代碼不一致，與其這樣，不如不寫。而假如在項目結束后寫文檔，開發(fā)人員往往已經忘記當時寫代碼時的種種考慮，況且有下一個項目的壓力，治理人員也不愿意再為舊的項目寫文檔，導致以后維護的問題。沒有人能保證需求不變動，以往項目往往對需求的變動大為頭疼，害怕這個改變會帶來其他地方的錯誤。為此，除了設計好的結構可以分割項目外（松耦合），但假如有了測試，并已經建立了一個好的測試框架，對于需求的變動，修改完代碼后，只要從新運行測試代碼，假如通過了測試，也保證了修改的成功，假如測試中出現錯誤，也會馬上發(fā)現錯在哪里，修改相應的部分，再運行測試，直到測試完全通過。

    根據xp的規(guī)定：寫代碼的人必須為自己的代碼寫測試，而且只有測試通過，才算完成這個任務（這里的測試包括所有的測試，假如測試時發(fā)現由于你的程序導致別的模塊的測試失敗，你有責任通知相關人員修改直至集成測試通過），這樣可以避免這類問題的發(fā)生。