Time上的小點表示測試個數，如果測試通過則顯示OK。否則在小點的后邊標上F，表示該測試失敗。
每次的測試結果都應該是OK的，這樣才能說明測試是成功的，如果不成功就要馬上根據提示信息進行修正了。
如果JUnit報告了測試沒有成功，它會區分失敗(failures)和錯誤(errors)。失敗是你的代碼中的assert方法失敗引起的;而錯誤則是代碼異常引起的，例如ArrayIndexOutOfBoundsException。
以圖形方式運行：
java junit.swingui.TestRunner junitfaq.SimpleTest
通過的測試結果在圖形界面的綠色條部分。
以上是最簡單的測試樣例，在實際的測試中我們測試某個類的功能是常常需要執行一些共同的操作，完成以后需要銷毀所占用的資源(例如網絡連接、數據庫連接，關閉打開的文件等)，TestCase類給我們提供了setUp方法和tearDown方法，setUp方法的內容在測試你編寫的TestCase子類的每個testXxxx方法之前都會運行，而tearDown方法的內容在每個testXxxx方法結束以后都會執行。這個既共享了初始化代碼，又消除了各個測試代碼之間可能產生的相互影響。
JUnit最佳實踐
Martin Fowler說過：“當你試圖打印輸出一些信息或調試一個表達式時，寫一些測試代碼來替代那些傳統的方法�！币婚_始，你會發現你總是要創建一些新的Fixture，而且測試似乎使你的編程速度慢了下來。然而不久之后，你會發現你重復使用相同的Fixture，而且新的測試通常只涉及添加一個新的測試方法。
你可能會寫許多測試代碼，但你很快就會發現你設想出的測試只有一小部分是真正有用的。你所需要的測試是那些會失敗的測試，即那些你認為不會失敗的測試，或你認為應該失敗卻成功的測試。
我們前面提到過測試是一個不會中斷的過程。一旦你有了一個測試，你就要一直確保其正常工作，以檢驗你所加入的新的工作代碼。不要每隔幾天或最后才運行測試，每天你都應該運行一下測試代碼。這種投資很小，但可以確保你得到可以信賴的工作代碼。你的返工率降低了，你會有更多的時間編寫工作代碼。
不要認為壓力大，就不寫測試代碼。相反編寫測試代碼會使你的壓力逐漸減輕，應為通過編寫測試代碼，你對類的行為有了確切的認識。你會更快地編寫出有效率地工作代碼。
下面是一些具體的編寫測試代碼的技巧或較好的實踐方法：
1. 不要用TestCase的構造函數初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依賴或假定測試運行的順序，因為JUnit利用Vector保存測試方法。所以不同的平臺會按不同的順序從Vector中取出測試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨后的測試依賴于某些特定的交易數據，就不要提交交易數據。簡單的會滾就可以了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
