單元測試是對系統中最小可測試單元的功能進行自動化測試，來驗證**功能是否符合預期。單元測試的意義雖說都很清楚，但是實際開發中寫出真正有意義的單元測試並不多或者說並不那麼容易，甚至很多專案是根本沒有單元測試的，本文旨在讓大家對單元測試有乙個完整的認識。實際開發中單元測試的困境
其實上面的問題筆者都遇到過，估計很多人都有類似的體會，也因為疏忽踩了一些坑。
老生常談：為什麼要寫單元測試
單元測試的最大價值就是盡快發現錯誤，稍有開發經驗的都有乙個體會：發現bug的時間比用來修復的時間要長的多。
以筆者為例，曾經修改了一行**，上線後貌似一切都正常，過了好幾天有使用者開始反饋問題，最後發現就是修改的那行**導致在某個特殊的場景會有問題的。如果這個錯誤能在跑單元測試的時候定位到，問題就可以上線前消除掉，而且這個場景在單元測試的時候完全可以覆蓋到，只是當時整個專案幾乎沒有單元測試，質量僅靠測試人員是不行的。
單元測試就是乙個bug偵測器，是保證**質量的乙個很重要的手段。
你寫的是單元測試嗎
單元測試規範
不依賴第三方環境和服務
如果單元測試有對外部環境(網路、服務、中介軟體)的依賴，那一旦依賴不穩定，就會造成單元測試的失敗，影響持續整合和測試進度。
自動化很多人在驗證資料時喜歡用log或者列印語句輸出內容，人工核對，這種單測不能暴漏錯誤，而且沒法自動化就沒法到持續整合，也就稱不上單元測試。
確保所有測試都完成自動化，讓它們自己檢查自己的測試結果。
單元測試要有足夠的強度
比如驗證一條insert sql，不僅要驗證是否成功執行，還要驗證一下插入的資料是否符合預期。只***足夠的強度，在**發生變化後，單測才能盡可能發現問題。
測試用例之間要相互隔離
測試用例之間要相互獨立，包括上下文環境獨立、資料獨立等，目的是避免測試用例的不穩定。
資料隔離
這就要求不要共用測試資料或測試資料要及時清除。
單元測試的速度要快
目的是為了盡快暴露問題，另外也可以避免持續整合的時間過長。這一條結合第一條，就要求將單測的外部依賴全部改成本地實現或者mock。
不要追求面面俱到的單元測試
如果每個方法、每個場景我們都努力去寫乙個單元測試用例，你會發現這是乙個相當龐大的**量，甚至比要測試的**還要多。如果我們這樣要求自己，我想多數人心裡是會有牴觸的，而且實際的開發中也未必允許我們有充裕的時間來這樣做。
單元測試的出發點是盡可能發現bug，我們要測試是你最擔心的可能會出錯的地方，抓住重點，測試收益反倒會事半功倍。
花合理時間抓出大多數bug好過窮盡一生抓出所有bug，也更符合實際的開發情況。
當然單元測試不是萬能的，但是沒有單元測試的**裸奔是不行的。記住，單元測試是程式不可分割的一部分！
重新認識測試
以前總覺得測試是軟體開發的邊緣職位，開發人員才是軟體生命週期的核心人員。隨著對網際網路公司的了解，逐步了解到測試的重要性。以bat為例，三家公司均設定了測試開發工程師崗位，該崗位的主要職責就是編寫自動化測試案例，通過對 的邏輯進行分析，設計出能夠覆蓋大部分 的測試用例。如阿里的測試開發工程師的崗位描...
重新認識container
我還清楚的記得，第一次從 那兒聽說container這個詞 結果他給我解釋了半天還是似懂非懂的。今天，偷閒翻了下posa4,發現裡面對container的解釋特別清楚。粗略的理解下來是，為了分離關注點，而實現的對系統資源的封裝。豁然開朗的發現，os就是應用程式的container。突發奇想的，開發乙...
重新認識ARC
雖然用了很久的arc，感受了 簡潔。但是對arc底層實現並不了解。今天抽空研究了下，做些簡單地總結。一 strong 1.區域性變數 對於區域性變數來說，在超出作用域的地方由編譯器自動插入release。大概轉化為 在非arc返回的autorelease型別的方法 在blog手碼大概 如有錯誤還望指...