以下是對JUnit實踐的一個很好的總結信息來源於一些比較權威的JUnit書籍和網上資料這裡集合如下
每次只對一個對象進行UT測試（unittest one object at a time）這樣能使你盡快發現問題而不被各個對象之間的復雜關系所迷惑
給測試方法起個好名字（choose meaningful test method names）應該是用形如testXXXYYY()這樣的格式來命名你的測試方法前綴test是Junit查找測試方法的依據XXX應該是你測試的方法名YYY應該是你測試的狀態當然如果你只有一種狀態需要測試可以直接命名為testXXX()
明確寫出出錯原因（explain the failure reason in assert calls）在使用assertTrueassertFalseassertNotNullassertNull方法時應該將可能的錯誤的描述字符串以第一個參數傳入相應的方法這樣你可以迅速的找出出錯原因
一個UT測試方法只應該測試一種情況（one unit test equals one testMethod）一個方法中的多次測試只會混亂你的測試目的
測試任何可能的錯誤（test anything that could possibly fail）你的測試代碼不是為了證明你是對的而是為了證明你沒有錯因此對測試的范圍要全面比如邊界值正常值錯誤值對代碼可能出現的問題要全面預測
讓你的測試幫助改善你的代碼（let the test improve the code）測試代碼永遠是我們代碼的第一個用戶所以不僅讓他幫組我們發現Bug還要幫組我們改善我們的設計就是有名的測試驅動開發（TestDriven DevelopmentTDD）
一樣的包不同的位置（same package separate directories）測試的代碼和被測試的代碼應該放到不同的文件夾中建議使用這種目錄 src/java/代碼 src/test/測試代碼 這樣可以讓兩份代碼使用一樣的包結構但是放在不同的目錄下
關於setup與teardown
a) 不要用TestCase的構造函數初始化Fixture而要用setUp()和tearDown()方法
b) 在setUp和tearDown中的代碼不應該是與測試方法相關的而應該是全局相關的如針對與測試方法都要用到的數據庫鏈接等等
c) 當繼承一個測試類時記得調用父類的setUp()和tearDown()方法
不要在mock object中牽扯到業務邏輯（dont write business logic in mock objects）
只對可能產生錯誤的地方進行測試（only test what can possibly break）如一個類中頻繁改動的函數對於那些僅僅只含有getter/setter的類如果是由IDE（如Eclipse）產生的則可不測如果是人工寫那麼最好測試一下
盡量不要依賴或假定測試運行的順序因為JUnit利用Vector保存測試方法所以不同的平台會按不同的順序從Vector中取出測試方法
避免編寫有副作用的TestCase你要確信保持你的測試方法之間是獨立的
將測試代碼和工作代碼放在一起一邊同步編譯和更新（使用Ant中有支持junit的task）
確保測試與時間無關不要依賴使用過期的數據進行測試導致在隨後的維護過程中很難重現測試
如果你編寫的軟件面向國際市場編寫測試時要考慮國際化的因素不要僅用母語的Locale進行測試
盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法可以使代碼更為簡潔
測試要盡可能地小執行速度快
……等待你的高見！
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28099.html
