Java語言是一個支持面向對象的語言，通常情況下我們可以將程序的一個單元看成是一個獨立的類，因此進行單元測試的重點就是對這些類進行測試。

　　1、不需要測試get和set這樣的行為

　　2、一個方法至少需要測試一次

　　二、測試步驟

　　1、判斷組件的功能：通過定義應用的整體需求，然后將系統劃分成幾個對象，我們需要對組件的基本功能十分清楚。因此，J2EE單元測試實際上也屬于設計過程的一部分。

　　2、設計組件行為：依據所處理的過程，可以通過一個正規或者非正規的過程實現組件行為的設計，我們可以使用UML或者其他文檔視圖來設計組件行為，從而為組件的測試打下基礎。

　　3、編寫單元測試程序（或測試用例）確認組件行為：這個階段，應該假定組件的編碼已經結束而組件工作正常，我們需要編寫單元測試程序來確定其功能是否和預定義的功能相同，測試程序需要考慮所有正常和意外的輸入，以及特定的方法能產生的溢出。

　　4、編寫組件并執行測試：首先，創建類及其所對應的方法標識，然后遍歷每個測試實例，為其編寫相應代碼使其順利通過，然后返回測試。繼續這個過程直至所有實例通過。此時，停止編碼。

　　5、測試替代品：對組件行為的其他方式進行考慮，設計更周全的輸入或者其他錯誤條件，編寫測試用例來捕獲這些條件，然后修改代碼使得測試通過。

　　6、重整代碼：如果有必要，在編碼結束時，對代碼進行重整和優化，改動后，返回單元測試并確認測試通過。

　　7、當組件有新的行為時，編寫新的測試用例：每次在組件中發現故障。編寫一個測試實例重復這個故障，然后修改組件以保證測試實例通過。同樣，當發現新的需求或已有的需求改變時，編寫或修改測試實例以響應此改變，然后修改代碼。

　　8、代碼修改,返回所有的測試：每次代碼修改時，返回所有的測試以確保沒有打亂代碼。

　　三、使用junit進行單元測試

　　摘要：1、每次只對一個對象進行UT測試；2、給測試方法起個好名字；3、明確寫出出錯原因；4、一個UT測試方法只應該測試一種情況；5、測試任何可能的錯誤；6、讓你的測試幫助改善你的代碼；7、一樣的包，不同的位置……

　　以下是對JUnit實踐的一個很好的總結，信息來源于一些比較權威的JUnit書籍和網上資料。這里集合如下：

　　1、每次只對一個對象進行UT測試（unit-test one object at a time）。這樣能使你盡快發現問題，而不被各個對象之間的復雜關系所迷惑。

　　2、給測試方法起個好名字（choose meaningful test method names）。應該是用形如testXXXYYY()，這樣的格式來命名你的測試方法。前綴test是Junit查找測試方法的依據，XXX應該是你測試 的方法名，YYY應該是你測試的狀態。當然如果你只有一種狀態需要測試可以直接命名為testXXX()。

　　3、明確寫出出錯原因（explain the failure reason in assert calls）。在使用assertTrue,assertFalse,assertNotNull,assertNull方法時，應該將可能的錯誤的描述 字符串，以第一個參數傳入相應的方法。這樣你可以迅速的找出出錯原因。

　　4、一個UT測試方法只應該測試一種情況（one unit test equals one testMethod）。一個方法中的多次測試，只會混亂你的測試目的。

　　5、測試任何可能的錯誤（test anything that could possibly fail）。你的測試代碼不是為了證明你是對的，而是為了證明你沒有錯。因此對測試的范圍要全面，比如邊界值、正常值、錯誤值；對代碼可能出現的問題要全 面預測。

　　6、讓你的測試幫助改善你的代碼（let the test improve the code）。測試代碼永遠是我們代碼的第一個用戶，所以不僅讓他幫組我們發現Bug,還要幫組我們改善我們的設計，就是有名的測試驅動開發（Test-Driven Development，TDD）。

　　7、一樣的包，不同的位置（same package, separate directories）。測試的代碼和被測試的代碼應該放到不同的文件夾中，建議使用這種目錄 src/java/代碼 src/test/測試代碼。 這樣可以讓兩份代碼使用一樣的包結構，但是放在不同的目錄下。

　　8、關于setup與teardown

　　a) 不要用TestCase的構造函數初始化Fixture，而要用setUp()和tearDown()方法。

　　b) 在setUp和tearDown中的代碼不應該是與測試方法相關的，而應該是全局相關的。如：針對與測試方法都要用到的數據庫鏈接等等。

　　c) 當繼承一個測試類時，記得調用父類的setUp()和tearDown()方法。

　　9、不要在mock object中牽扯到業務邏輯（don’t write business logic in mock objects）。

　　10、只對可能產生錯誤的地方進行測試（only test what can possibly break）。如：一個類中頻繁改動的函數。對于那些僅僅只含有getter/setter的類，如果是由IDE（如Eclipse）產生的，則可不測； 如果是人工寫，那么最好測試一下。

　　11、盡量不要依賴或假定測試運行的順序，因為JUnit利用Vector保存測試方法。所以不同的平臺會按不同的順序從Vector中取出測試方法。

　　12、避免編寫有副作用的TestCase，你要確信保持你的測試方法之間是獨立的。

　　13、將測試代碼和工作代碼放在一起，一邊同步編譯和更新（使用Ant中有支持junit的task）。

　　14、確保測試與時間無關，不要依賴使用過期的數據進行測試。導致在隨后的維護過程中很難重現測試。

　　15、如果你編寫的軟件面向國際市場，編寫測試時要考慮國際化的因素。不要僅用母語的Locale進行測試。

　　16、盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡潔。

　　17、測試要盡可能地小，執行速度快。

原文：http://www.51testing.com/?action_viewnews_itemid_89418.html