單元測試中，每個測試類，甚至測試方法最好沒有依賴，這樣有很多好處：1.每個測試類都可以單獨執行並能成功；2.修改乙個測試類不會對其它類造成影響。這也是為什麼junit中提供setup()和teardown()的原因之一。
一般情況下，大家喜歡在setup()中建立環境，執行完測試，在teardown()中清除環境，這樣互相不依賴。我把這種情況叫做「利他」，即你相信別人，別人也相信你。這對很多單元測試都沒問題。
但是有時候你是否遇見過這樣的問題：
1.跟其他同事協作開發時，你對自己寫的單元測試了然於胸，但是未免不會心裡打鼓：萬一別人teardown()不正確，並對我的測試有影響了怎麼辦？
一般情況下，大家需要實現商量好，比如都同意在setup()建立環境，teardown()清除環境。
2.即使跟其他同事商量好了setup()、teardown()的職責，你是否遇到過這樣的情況呢？
在ide裡面跑某個dao類所有的測試方法（可能測試方法比較多，需要的時間比較長），剛點了執行，突然發現某些地方寫錯了，或者其它原因，你直接終止了執行。這樣就造成了不希望的後果：下次執行測試也會失敗，因為你強行終止了程序，沒有來得及teardown()。於是下一次執行測試之前，你不得不通過sql或者其它辦法先把資料庫裡的資料清理一下。
3.你在執行所有單元測試的過程中，發現某個dao測試失敗了，經過仔細debug，花費了很多時間，發現竟然是前乙個dao測試沒有清理完全資料，雖然之前你和同事已經商量過了。
同樣，在功能測試中也可能遇到前面所提的問題。那麼有更好的辦法嗎？
很多人可能已經實踐過這樣寫單元測試（尤其是dao等代價比較高的測試），把清理環境和建立環境都放到setup()時做。這樣肯定保證了自己單元測試的順利執行。我認為這種方式是「利己」的方式，但是在這種情況下卻是非常合適的方式。雖然利己，但是如果大家事先生命，而且人人保證自己沒問題，那麼所有的單元測試一塊跑起來問題也就不大。
單元測試與Junit
1，軟體的生命週期 需求，分析，開發，測試，維護。維護的成本最高。測試做好了可以降低維護成本。2，測試技術分類 1 按規模分類 2 按方法分類 3，junit 隨著系統規模的逐漸增大，每次修改完 都要重新啟動系統進行系統及測試十分耗時，junit可以通過測試類對系統中的單個方法進行測試，而不需要執行...
斷言與單元測試
using system using system.collections.generic using system.linq using system.text using microsoft.visualstudio.testtools.unittesting 路徑 c windows micr...
Python中的單元測試
今晚試了一下python自帶的單元測試，主要是參考了python單元測試框架 的有關資料，折騰了乙個小時左右，總算在eric 4通過的幾個簡單的單元測試。在這裡將所得的相關知識記錄下來，方便將來查詢。python自帶的單元測試模組是unittest，從2.1以後為標準庫的一部分 1 測試模組impo...