7.JUnit最佳實踐
Martin Fowler(又是這位高人)說過:“當你試圖打印輸出一些信息或調試一個表達式時,寫一些測試代碼來替代那些傳統的方法!币婚_始,你會發現你總是要創建一些新的Fixture,而且測試似乎使你的編程速度慢了下來。然而不久之后,你會發現你重復使用相同的Fixture,而且新的測試通常只涉及添加一個新的測試方法。
你可能會寫許多測試代碼,但你很快就會發現你設想出的測試只有一小部分是真正有用的。你所需要的測試是那些會失敗的測試,即那些你認為不會失敗的測試,或你認為應該失敗卻成功的測試。
我們前面提到過測試是一個不會中斷的過程。一旦你有了一個測試,你就要一直確保其正常工作,以檢驗你所加入的新的工作代碼。不要每隔幾天或最后才運行測試,每天你都應該運行一下測試代碼。這種投資很小,但可以確保你得到可以信賴的工作代碼。你的返工率降低了,你會有更多的時間編寫工作代碼。
不要認為壓力大,就不寫測試代碼。相反編寫測試代碼會使你的壓力逐漸減輕,應為通過編寫測試代碼,你對類的行為有了確切的認識。你會更快地編寫出有效率地工作代碼。下面是一些具體的編寫測試代碼的技巧或較好的實踐方法:
1. 不要用TestCase的構造函數初始化Fixture,而要用setUp()和tearDown()方法。 2. 不要依賴或假定測試運行的順序,因為JUnit利用Vector保存測試方法。所以不同的平臺會按不同的順序從Vector中取出測試方法。 3. 避免編寫有副作用的TestCase。例如:如果隨后的測試依賴于某些特定的交易數據,就不要提交交易數據。簡單的會滾就可以了。 4. 當繼承一個測試類時,記得調用父類的setUp()和tearDown()方法。 5. 將測試代碼和工作代碼放在一起,一邊同步編譯和更新。(使用Ant中有支持junit的task.) 6. 測試類和測試方法應該有一致的命名方案。如在工作類名前加上test從而形成測試類名。 7. 確保測試與時間無關,不要依賴使用過期的數據進行測試。導致在隨后的維護過程中很難重現測試。 8. 如果你編寫的軟件面向國際市場,編寫測試時要考慮國際化的因素。不要僅用母語的Locale進行測試。 9. 盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法,可以使代碼更為簡潔。 10.測試要盡可能地小,執行速度快。
事實上,JUnit還可用于集成測試,但我并沒涉及到,原因有兩個:一是因為沒有單元測試,集成測試無從談起。我們接受測試地概念已經很不容易了,如果再引入集成測試就會更困難。二是我比較懶,希望將集成測試的任務交給測試人員去做。在JUnit的網站上有一些相關的文章,有空大家可以翻一翻。
8.JUnit與J2EE
如果大家仔細考慮一下的話,就會發現,JUnit有自己的局限性,比如對圖形界面的測試,對servlet/JSP以及EJB的測試我們都沒有舉相關的例子。實際上,JUnit對于GUI界面,servlet/JSP,JavaBean以及EJB都有辦法測試。關于GUI的測試比較復雜,適合用一整篇文章來介紹。這里就不多說了。
前面我們所做的測試實際上有一個隱含的環境,JVM我們的類需要這個JVM來執行。而在J2EE框架中,servlet/JSP,EJB都要求有自己的運行環境:Web Container和EJB Container。所以,要想對servlet/JSP,EJB進行測試就需要將其部署在相應的Container中才能進行測試。由于EJB不涉及UI的問題(除非EJB操作XML數據,此時的測試代碼比較難寫,有可能需要你比較兩棵DOM樹是否含有相同的內容)只要部署上去之后就可以運行測試代碼了。此時setUp()方法顯得特別有用,你可以在setUp()方法中利用JNDI查找特定的EJB。而在testXXX()方法中調用并測試這些EJB的方法。
這里所指的JavaBean同樣沒有UI的問題,比如,我們用JavaBean來訪問數據庫,或用JavaBean來包裹EJB。如果這類JavaBean沒有用到Container的提供的服務,則可直接進行測試,同我們前面所說的一般的類的測試方法一樣。如果這類JavaBean用到了Container的提供的服務,則需要將其部署在Container中才能進行測試。方法與EJB類似。
對于servlet/JSP的測試則比較棘手,有人建議在測試代碼中構造HttpRequest和HttpResponse,然后進行比較,這就要求開發人員對HTTP協議以及servlet/JSP的內部實現有比較深的認識。我認為這招不太現實。也有人提出使用HttpUnit。由于我對Cactus和HttpUnit 了解不多,所以無法做出合適的建議。希望各位先知們能不吝賜教(ericwq@263.net)。
正是由于JUnit的開放性和簡單易行,才會引出這篇介紹文章。但技術總在不斷地更新,而且我對測試并沒有非常深入的理解;我可以將一個復雜的概念簡化成一句非常容易理解的話。但我的本意只是希望能降低開發人員步入測試領域的門檻,而不是要修改或重新定義一些概念。這一點是特別要強調的。最后,如果有些兄弟姐妹能給我(ericwq@263.net)指出一些注意事項或我對某些問題的理解有誤,我會非常感激的。
2001年冬雨(唉,已經下了10幾天的雨了)上海
|