1讓機器去做重複的事，而不是每次都由程式設計師配置引數、開啟ide專案、編譯、執行、使用程式、跟蹤斷點、檢視變數，如果想檢視「底層」改動對用例帶來的影響，執行單元測試就看見了，當然增加的邏輯單元和需求單元得額外得寫新的單元測試。
2 作為程式改進設計的依據，如果你現在的對一段**的想法是沒法去測試，基本可以「斷言」它是需要改進的。因為一段程式總會有所影響，帶來一些改變，無論是持久化資料的、物件狀態、檔案內容，而大多數介面則總是有著輸入輸出，這個時候單元測試關心的就是如何驗證它們，這其實也讓我們時刻明確著寫**的目的，我要改變什麼，然後告訴別人我寫對了，如果沒法告訴測試用例你是對的，真不知道出錯的時候你會和別人怎麼說(哈哈)。
3讓你更加獨立的完成自己的事，如果要測試的單元執行環境很複雜，讓你覺得上下文配置不好協調，很麻煩~那就忽略它們，因為mock物件設計出來就是幫你幹這事的——別去管別人的介面內部變動或者沒完成的部分。除非介面的設計增加或減少了，否則你只需要關心自己已經完成的以及剛剛改掉的地方，不必經歷配置引數、造資料記錄或每次手動輸入引數、ping通伺服器，然後一路"f5 + f10"千里迢迢找到它(當然第一次執行時候還是得考慮好怎麼構造)，對你的mock跑過單元測試後，你就可以提交**去看新聞了。
4讓團隊更好地協作，你肯定不想總去給別人講你寫的程式**應該怎麼呼叫（對團隊內的新人或需要交叉結對的情景時），也肯定不覺得自己寫的文件所有人都會去看（或者誰都能有耐心去看懂），這時你專案中的測試專案就出現了用處，看到你是怎麼呼叫某個模組去進行測試的，我覺得80%以上的人都會閉嘴然後自己去寫**自己試試（因為你的用例都亮綠燈了嘛,除非他對顏色不那麼敏感……），剩下的可能會對你沒考慮過的情況或場景提出改進的建議，這時候你交朋友的機會來了，一起討論程式應該怎麼改吧！(當然也有些人比較有意思，他不屬於以上這兩種，那你考慮一下怎麼「幫」他/她吧，也許她/他是想接近你 ^——^)。
單元測試（1）
為什麼引入單元測試 單元測試 對軟體設計的最小單元進行正確性檢測的測試，將可能存在的錯誤在最小範圍內發現解決 單元測試的目的 發現模組內部邏輯，語法，演算法，功能的錯誤 單元測試方法 級別測試和模組功能測試 級別測試 熟悉模組功能，內部邏輯與介面，編寫測試用例 1.介面測試 確保資料結構可用，例如資...
單元測試1
總結應該盡早地進行軟體單元測試。應該保證單元測試的可重複性。盡可能地採用測試自動化的手段來支援單元測試活動。單元模組被正確編碼 資訊能否正確地流入和流出單元 在單元工作過程中，其內部資料能否保持其完整性，包括內部資料的形式 內容及相互關係不發生錯誤，也包括全域性變數在單元中的處理和影響。在為限制資料...
單元測試1
python為我們提供了unittest包用來進行單元測試，還是以count這個類為例。class count def init self,a,b self.a a self.b b defadd self return self.a self.b下面就對count進行單元測試。import uni...