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