為什么要編寫單元測試？原因是單元測試有不少的優點，能夠給我們的工作帶來很大的幫助。單元測試的優點1.幫助開發人員編寫代碼，提升質量、減少bug。如果大家分析一下我們bug原因的構成，我想有會有一部分bug的原因是開發人員在編寫工作代碼的時候沒有考慮到某些case或者邊際條件。造成這種問題的原因很多，其中很重要的一個原因是我們對工作代碼所要完成的功能思考不足，而編寫單元測試，特別是先寫單元測試再寫工作代碼就可以幫助開發人員思考編寫的代碼到底要實現哪些功能。例如實現一個簡單的用戶注冊功能的業務類方法，用單元測試再寫工作代碼的方式來工作的話開發人員就會先考慮各種場景相關，例如正常注冊、用戶名重復、沒有滿足必要的填寫內容......等等，之后就會編寫相關的測試用例public Class UserSerivceTest(){
public userRegister_Ok(){
......}public userRegister_nameDuplicated(){
......}}編寫單元測試代碼的過程就是促使開發人員思考工作代碼實現內容和邏輯的過程，之后實現工作代碼的時候，開發人員思路會更清晰，實現代碼的質量也會有相應的提升。2.提升反饋速度，減少重復工作，提高開發效率。開發人員實現某個功能或者修補了某個bug，如果有相應的單元測試支持的話，開發人員可以馬上通過運行單元測試來驗證之前完成的代碼是否正確，而不需要反復通過發布war包、啟動jboss、通過瀏覽器輸入數據等繁瑣的步驟來驗證所完成的功能。用單元測試代碼來驗證代碼和通過發布應用以人工的方式來驗證代碼這兩者的效率差很多，看到很多開發人員每天要反復執行N次發布腳本（antx之類的工具）真是痛苦。3.保證你最后的代碼修改不會破壞之前代碼的功能。項目越做越大，代碼越來越多，特別涉及到一些公用接口之類的代碼或是底層的基礎庫，誰也不敢保證這次修改的代碼不會破壞之前的功能，所以與此相關的需求會被擱置或推遲，由于不敢改進代碼，代碼也變得越來越難以維護，質量也越來越差。而單元測試就是解決這種問題的很好方法（不敢說最好的）。由于代碼的歷史功能都有相應的單元測試保證，修改了某些代碼以后，通過運行相關的單元測試就可以驗證出新調整的功能是否有影響到之前的功能。當然要實現到這種程度需要很大的付出，不但要能夠達到比較高的測試覆蓋率，而且單元測試代碼的編寫質量也要有保證。4.讓代碼維護更容易。由于給代碼寫很多單元測試，相當于給代碼加上了規格說明書，開發人員通過讀單元測試代碼也能夠幫助開發人員理解現有代碼。很有opensource的項目都有相當量的單元測試代碼，通過讀這些測試代碼會有助于理解生產源代碼。5.有助于改進代碼質量和設計。除了那些大拿們編寫的代碼，我相信很多易于維護、設計良好的代碼都是通過不斷的重構才得到的。雖然說單元測試本身不能直接改進生產代碼的質量，但它為生產代碼提供了“安全網”，讓開發人員可以勇敢地改進代碼，從而讓代碼的clean和beautiful不再是夢想。單元測試的缺點1.單元測試的學習成本比較高。編寫單元測試涉及的技術很多，如果只是單純的使用Junit或是TestNG這樣的基礎單元測試框架往往很難應對各種復雜的單元測試情況，所以勢必要借助很多第三方的框架和技術（easymock，jmock，dbunit等等），這些框架和技術的學習還是會增加學習的成本和難度。2.編寫單元測試會增加程序員工作量。單元測試跟生產代碼是一樣的，并不會應為是用來測試的就有所不同，開發人員同樣要面對測試代碼的編寫、維護等工作，也同樣要面對避免重復代碼等一系列問題，能否寫出好的測試代碼還是取決于開發人員的設計和編碼能力。3.推廣和運用單元測試需要比較大的投入。只有在每個開發人員都編寫了足夠的、質量好的單元測試代碼，大家才能真正享受到單元測試帶給我們的好處。在達到這種層度以前，還需要不少實現和資源的投入?？偨Y雖然單元測試也有一些缺點和負面的效應，但跟單元測試的優點比較起來，為了克服和解決這些缺點所在的付出是值得的。