最近一段時間跟朋友溝通到單元測試的問題，朋友吐槽公司技術大佬對於單元測試完全是不接受狀態，質量工作完全由測試人員通過ui自動化、手工黑盒測試完成，導致測試人員異常痛苦，每次開發人員交付的**幾乎接近不可執行狀態。
我最近也就單元測試諮詢了一些技術大佬的看法，加上對我參與、了解的所有團隊單元測試做法的回顧。發現對於不同的團隊、不同的技術背景，對於單元測試的認同度、測試策略都是不相同的（有完全認為沒有必要浪費時間的、有非常認同要求單測覆蓋率達到90%並且要求單測必過的）。簡單整理一下個人對於單元測試的認知和看法。
我覺得大家對它有不同的認知和看法的主要原因是這個最小單元到底怎麼定義？**層面的乙個函式、乙個類、業務層面的乙個功能邏輯、乙個介面？
我認為首先需要對單元測試進行分層
應對不同的層次需要使用不同的方式，例如我認為基礎**層（即公共函式）一定要進行單元測試，業務**層可以根據團隊情況選擇只做業務介面測試、還是全部都進行測試覆蓋（業務介面基本可間接覆蓋所有業務**）。
另外單元測試也不僅是後端需要，前端也是有需要進行單元測試的，前端也有大量的公共組建、公共方法、邏輯處理。
我理解的測試階段包括：單元測試、整合測試、端到端測試。
單元測試有優點：
當然單元測試也有缺點：
對於單元測試的使用，需要參考它的優缺點，不能完全膜拜，也不能完全否定
其實從單元測試與其他測試區別分析就可以看出，理論上端到端測試可以完全覆蓋所有測試，那單元測試還有沒有必要做呢？
我認為有必要並且非常有必要，為什麼？
單元測試有誰來做比較好，我認為開發來做比較好。為什麼說開發來做最好？（當然介於種種原因公司有單獨負責單元測試的團隊也是可以的）
單元測試策略的制定並不是一概而論的，不同的團隊就需要不同的策略方法。
但是有一點個人認為，無論是否是網際網路專案，單元測試越高的覆蓋率對於質量保證支援越高，可以慢慢補充、但不可以不做。
單元測試其實已經有著豐富的工具，支援編寫、執行、統計，例如：
很多團隊的做法是將單元測試的統計整合在sonar中沒完成靜態**的掃瞄和統計，可以參考sonar與**檢測分析
我見到有很多團隊實力推薦tdd（測試驅動開發），也有很多團隊拒絕tdd。
我個人認為tdd是一種很好的開發方法，先整理業務場景和測試點，然後根據業務場景和測試點進行編碼。這種方式大大的增強了開發人員對於業務的理解，對於減少bug的有著極大的幫助。
但是很多團隊拒絕的原因也很明顯，太消耗時間，需要開發梳理各種業務場景、測試點。
對於梳理業務過於消耗時間這件事，我認為是團隊資源的未充分利用和嚴重的「深井病」。為什麼這樣說，梳理業務場景有沒有發現這件事情產品經理、測試人員都在做，產品經理梳理使用者旅程、測試人員在此基礎上幫助豐富各種業務場景，既然有人做了這件事為什麼不能直接拿來用呢？
理解單元測試 Unit Testing
本文的目的是以最精煉的語言，正解什麼是單元測試，為什麼要單元測試，和如何進行單元測試。測試 testing 這個詞很容易理解，那麼什麼是單元 unit 呢？乙個單元指的是應用程式中可測試的最小的一組源 一組源 可測試，一般要求其有明確的輸入和輸出。因此，一般來講，源 中包含明確的輸入和輸出的每乙個方...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...