整體內容順序轉載自百度百科：junit 下面也添加了自己的見解
以前在做單元測試時不怎麼注意，感覺單元測試有時候是多餘的，但是現在工作了，才知道原來單元測試這麼牛逼，雖然簡單，但是裏面的東西會很幫助我們，如果你現在還只是簡單的運用junit，而不是在項目裏時刻的用到，那麼你可能很牛逼了，竟然靠經驗就可以知道這個有沒有bug。
Junit是一個java語言的單元測試框架，也是迴歸測試框架，在軟件軟工中也叫白盒測試，繼承TestCase類(Junit4的測試類不用再繼承TestCase父類，引入了Annotation(註解))
一、junit的優點
- 極限編程：要求在編寫代碼前先寫測試，這樣可以強制你在寫代碼之前好好思考代碼的功能與邏輯，否則編寫的代碼很不穩定，也通俗的叫在寫代碼前自己想想你這個方法根據參數想得到的結果是什麼？ 也可以認爲是從結果出發，所以很鍛鍊你的思維，讓你養成極限的思維：構思->編寫測試代碼->編寫代碼->測試。而且可以很快的找到問題的原因，不怕以後忙起來忘了這裏原來是怎麼測試的，並進行重複繁瑣的測試工作。
- 重構：這個也是改一點測一點，減少迴歸錯誤造成的時間消耗，就算重構也不會影響你這個犯法返回的結果什麼，重構只是讓代碼更加簡潔，更加易懂，得到的結果如果改變，就不叫重構了。
- 自動化：以前我們自己測試要debug打斷點或者輸出結果看看，這樣增加了自己的工作量，影響我們的效率，尤其是對於複用的方法，如果裏面的邏輯變了，是否會得到我們想要的結果。而junit就幫我們全部做了，它有斷言功能，Assert來對結果進行比較，是否符合自己的預期，非常方便。比如java肯定要面向接口編程，那一個接口服務就可以做一個單元測試，當服務裏面的邏輯更改後，只需要動動鼠標就知道自己的這個服務是否能得到自己想要的結果
- 隔離性：這個就需要我們自己去設置，一般推薦測試用例不要是歷史數據，因爲一旦丟失，單元測試就會失敗。需要注意的是單元測試類的單元測試方法之間是互不干擾的，而且執行順序是不可預測的，不要想着先執行這個單元測試，留下結果給下一個單元測試，這是非常不對的，。
二、用junit需要注意的事情
- 不要用TestCase的構造函數初始化Fixture，而要用
setUp()和tearDown()，junit4就可以用**@Before**和 @After代替 - 不要依賴或假定測試運行的順序，因爲Junit利用
Vertor保存測試方法，所以不同的平臺會按不同的順序從Vertor中取出測試方法。 - 避免編寫有副作用的TestCase，如果測試數據依賴於某些特定的交易數據，就不要提交交易數據，簡單回滾就可以(前提是需要設置事務)
- 測試類和測試方法應該有一致的命名方案，如在工作類名前加Test形成測試類名，方法名前加test
- 確保測試與時間無關，不要依賴使用過期的數據，導致後期維護過程很難重現測試，尤其是你用的數據被刪除了
- 如果編寫的軟件面向國際市場，編寫測試時就要考慮國際化的因素，不要僅用母語的Local進行測試。
- 儘可能的利用Junit提供的Assert/Fail方法以及異常處理的方法，可以使代碼簡潔、高效，自動化。
- 測試儘可能的小（一個方法一個單元測試一般不會這樣，自己一般是一個服務一個單元測試方法，一個
Controller一個單元測試方法），執行速度快(這個就要看你這個測試有沒有時間要求) - 不要硬性規定數據文件的路徑，尤其是本地文件，否則再別的機器上可能就會找不到路徑
- 利用Junit的自動異常處理，不用在測試方法裏寫
try{}catch{}，Junit 會自動捕獲異常。那些沒有被捕獲的異常就被當成錯誤處理。