1. 單元測試的目的
一個單元測試從整個系統中單獨檢驗產品程序代碼的『一個單元』并檢查其得到的結果是否是預期的。要測試的『一個單元』其大小是依據一組連貫的功能的大小及介于一個類別及一個包(package)之間實際上的變化(varies)。其目的是在整合程序代碼到系統的其余部分之前先測試以便找出程序代碼中的臭蟲（bugs）。Junit等支持在Java程序代碼中撰寫單元測試。
在整合之前于系統其它部分隔離起來抓蟲的理由是因為那是比較容易的找到臭蟲（亦即比較快且便宜）及比較容易修正問題（并顯示其解決方式是可行的）。
單元測試對于在初始整合一小部分程序代碼以及整合其余的改變之前提供了一些利益。如果有人需要變動現有的程序代碼，事實上單元測試仍然可以讓他對于其最后的程序代碼更有信心；即他的改變不會破壞任何東西。愈好的單元測試讓人愈有信心--理想上測試必須在加入的新功能前也隨之更新。
2. 誰來撰寫單元測試及何時撰寫單元測試
程序代碼測試可能是非常乏味的，尤其是測試別人的程序，而當你是一個程序設計師的時候尤甚。但程序設計師喜歡撰寫程序，因此為什么不讓程序設計師撰寫一些程序可以作為測試之用呢？
當單元測試正確的實作可以幫助程序設計師變的更有生產力，而同時提升開發程序代碼的品質。有一點你必須了解的是單元測試應該是開發程序的一部份是很重要的；而且程序代碼的設計必須是可以測試的。目前的趨勢是在撰寫程序代碼之前要先撰寫單元測試，并且把焦點放在Java類別的接口及行為上。
先寫測試，再寫代碼的好處：
從技術上強制設計師先考慮一個類的功能，也就是這個類提供給外部的接口，而不至于太早陷入它的細節。這是面向對象提倡的一種設計原則。
好的測試其實就是一個好的文檔，這個類使用者往往可以通過查看這個類的測試代碼了解它的功能。特別的，如果你拿到別人的一個程序，對他寫測試是最好的了解這個程序的功能的方法。xp的原則是make it simple，不是很推薦另外寫文檔，因為項目在開發過程中往往處于變動中，如果在早期寫文檔，以后代碼變動后還得同步文檔，多了一個工作，而且由于項目時間緊往往文檔寫的不全或與代碼不一致，與其這樣，不如不寫。而如果在項目結束后再寫文檔，開發人員往往已經忘記當時寫代碼時的種種考慮，況且有下一個項目的壓力，管理人員也不愿意再為舊的項目寫文檔。導致以后維護的問題
沒有人能保證需求不變動，以往項目往往對需求的變動大為頭疼，害怕這個改動會帶來其它地方的錯誤。為此，除了設計好的結構以分割項目外（松耦合），但如果有了測試，并已經建立了一個好的測試框架，對于需求的變動，修改完代碼后，只要重新運行測試代碼，如果測試通過，也就保證了修改的成功，如果測試中出現錯誤，也會馬上發現錯在哪里。修改相應的部分，再運行測試，直至測試完全通過。
軟件公司里往往存在開發部門和測試部門之間的矛盾：由于開發和測試分為兩個部門，多了一層溝通的成本和時間，溝通往往會產生錯誤的發生。而且極易形成一個怪圈：開發人員為了趕任務，寫了爛爛的代碼，就把它扔給測試人員，然后寫其它的任務，測試當然是失敗的，又把代碼拿回去重寫，測試就成了一個很頭疼的問題。這種怪圈的根源是責任不清，根據xp中的規定：寫這個代碼的人必須為自己的代碼寫測試，而且只有測試通過，才算完成這個任務（這里的測試包括所有的測試，如果測試時發現由于你的程序導致別的組的測試失敗，你有責任通知相關人員修改直至集成測試通過），這樣就可以避免這類問題的發生。
簡而言之，如果程序設計師要寫一段代碼：
先用junit寫測試，然后再寫代碼;
寫完代碼，運行測試，如果測試失敗，
修改代碼，運行測試，直到測試成功。
如果以后對程序進行修改，優化( refactoring )，只要再運行測試代碼。如果所有的測試都成功，則代碼修改完成。
文章來源于領測軟件測試網 http://www.kjueaiud.com/