本文的目的是以最精煉的語言，正解什麼是單元測試，為什麼要單元測試，和如何進行單元測試。
測試(testing)這個詞很容易理解，那麼什麼是單元(unit)呢？乙個單元指的是應用程式中可測試的最小的一組源**。一組源**可測試，一般要求其有明確的輸入和輸出。因此，一般來講，源**中包含明確的輸入和輸出的每乙個方法被認為是乙個可測試的單元。注意，這裡指的輸出，並不侷限於方法的返回值或對輸入引數的改變，而包括了方法的執行過程中，改變的任何資料。
單元測試的目的，是將應用程式的所有源**，隔離成最小的可測試的單元，保證每個單元的正確性。理想情況下，如果每個單元都能保證正確，就能保證應用程式整體相當程度的正確性。
另一方面，單元測試也是一種特殊型別的文件，相對於書面的文件，測試指令碼本身往往就是對被測試**的實際的使用**，對於幫助開發人員理解被測試單元的使用是相當有幫助的。
隔離要進行單元測試，首先就是要將被測試的單元，與所有外部依賴進行隔離。一般來講，進行隔離主要有兩種可選的技術，一種叫stub，一種叫mock。對於兩個的區別和取捨，martin fowler有乙個很經典的文章：mocks aren't stubs。簡單來說，如果要stub或mock乙個方法，stub指的是，為了測試，手動寫乙個相同簽名的方法，根據我的測試需要，對給定的輸入引數，返回一定的輸出；而mock則借助一定的框架元件，自動生成乙個方法的實現，對於給定的輸入，返回一定的輸出。當然，所謂的stub或mock，並不單指對方法，尤其是在物件導向程式設計中，也可以是對屬性，對物件或者對介面，等等。
為了方便實現隔離，對軟體設計和開發的乙個潛在的激勵是，軟體模組的設計人員和開發人員，不得不時時思考，在當前語言支援的各種特性的條件下，如何使得所寫的**，能夠被方便的被隔離。雖然這看起來很像是一種限制，但是和軟體設計的solid原則，其實是不謀而合的，因此，也就未嘗不是乙個優點了。
測試解決了隔離的問題，我們就可以關注對乙個單元的測試本身了。首先要提的一點是，所謂測試乙個單元，一般往往是寫一段測試指令碼，給定輸入，驗證輸出。但是，其實並非所有的單元測試都可以完全由計算機方便地自動完成的。尤其是如圖形ui這樣的比較抽象元素的判斷。因此，從相對廣義的角度來說，凡是能夠用於驗證乙個被測試的單元正確性的所有方法進行的測試，都可以被認為是有效的測試。
自動化解決了隔離和測試本身的問題，下乙個需要討論的就是測試的效率的問題。儘管上面提到了，所謂單元測試，不完全都可以由計算機方便地自動完成，但是，對於那些可以由計算機自動完成的單元測試，如何提高寫測試**和執行測試的效率呢？答案是，陸續出現了很多的測試框架和測試工具。這些測試框架或工具，一般都會提供提高建立測試指令碼效率的工具，並且，提供自動化執行測試和檢視執行結果的功能，往往還可以很方便的和**的自動化編譯和部署進行整合，使測試自動化。
guidelines
單元測試理解
最近一段時間跟朋友溝通到單元測試的問題，朋友吐槽公司技術大佬對於單元測試完全是不接受狀態，質量工作完全由測試人員通過ui自動化 手工黑盒測試完成，導致測試人員異常痛苦，每次開發人員交付的 幾乎接近不可執行狀態。我最近也就單元測試諮詢了一些技術大佬的看法，加上對我參與 了解的所有團隊單元測試做法的回顧...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...