Junit是對(duì)程序代碼進(jìn)行單元測(cè)試的一種Java框架。通過每次修改程序之后測(cè)試代碼，程序員可以保證代碼的少量變動(dòng)不會(huì)破壞整個(gè)系統(tǒng)。要不是有Junit這樣的自動(dòng)化測(cè)試工具，代碼的反復(fù)測(cè)試簡(jiǎn)直會(huì)把人累死而且還可能不準(zhǔn)確�，F(xiàn)在好了，測(cè)試過程可以頻繁的進(jìn)行而且還是自動(dòng)的，所以你可以令程序錯(cuò)誤減低到少。它寫的是單元測(cè)試（Unit Test）：軟件工程里的白盒測(cè)試，是測(cè)試某個(gè)類的某個(gè)方法的功能，XP中推崇的test first design是基于以上技術(shù)的。
假如你要寫一段代碼：
1：先用Junit寫測(cè)試，然后再寫代碼。
2：寫完代碼，運(yùn)行測(cè)試，測(cè)試失敗。
3：修改代碼，運(yùn)行測(cè)試，直到測(cè)試成功。
假如以后對(duì)程序進(jìn)行修改，優(yōu)化（refactoring），只要再運(yùn)行測(cè)試代碼，假如所有的測(cè)試都成功，則代碼修改完成。
Java下的team開發(fā)，一般采用cvs（版本控制），ant（項(xiàng)目治理），Junit（單元測(cè)試）的模式。
先寫測(cè)試，再寫代碼的好處：
從技術(shù)上強(qiáng)制你先考慮一個(gè)類的功能，也是這個(gè)類提供給外部的借口，而不至于太早陷入它的細(xì)節(jié)。這是面向?qū)ο筇岢囊环N設(shè)計(jì)原則。好的測(cè)試其實(shí)是一個(gè)好的文檔，這個(gè)類使用者往往可以通過查看這個(gè)類的測(cè)試代碼了解它的功能。一般的，假如你拿到別人的程序，對(duì)他寫的測(cè)試解讀是了解程序工程的好的方法。xp原則是make it simple，不是很推薦另外的文檔，因?yàn)轫?xiàng)目在開發(fā)過程中往往處于變動(dòng)中，假如在早期寫文檔，以后代碼變動(dòng)還得的同步文檔，多了一個(gè)工作，而且由于項(xiàng)目時(shí)間緊，往往文檔寫的不全或者與代碼不一致，與其這樣，不如不寫。而假如在項(xiàng)目結(jié)束后寫文檔，開發(fā)人員往往已經(jīng)忘記當(dāng)時(shí)寫代碼時(shí)的種種考慮，況且有下一個(gè)項(xiàng)目的壓力，治理人員也不愿意再為舊的項(xiàng)目寫文檔，導(dǎo)致以后維護(hù)的問題。沒有人能保證需求不變動(dòng)，以往項(xiàng)目往往對(duì)需求的變動(dòng)大為頭疼，害怕這個(gè)改變會(huì)帶來其他地方的錯(cuò)誤。為此，除了設(shè)計(jì)好的結(jié)構(gòu)可以分割項(xiàng)目外（松耦合），但假如有了測(cè)試，并已經(jīng)建立了一個(gè)好的測(cè)試框架，對(duì)于需求的變動(dòng)，修改完代碼后，只要從新運(yùn)行測(cè)試代碼，假如通過了測(cè)試，也保證了修改的成功，假如測(cè)試中出現(xiàn)錯(cuò)誤，也會(huì)馬上發(fā)現(xiàn)錯(cuò)在哪里，修改相應(yīng)的部分，再運(yùn)行測(cè)試，直到測(cè)試完全通過。
根據(jù)xp的規(guī)定：寫代碼的人必須為自己的代碼寫測(cè)試，而且只有測(cè)試通過，才算完成這個(gè)任務(wù)（這里的測(cè)試包括所有的測(cè)試，假如測(cè)試時(shí)發(fā)現(xiàn)由于你的程序?qū)е聞e的模塊的測(cè)試失敗，你有責(zé)任通知相關(guān)人員修改直至集成測(cè)試通過），這樣可以避免這類問題的發(fā)生。
