大型企業通常如何進行單元測試？
你平時是怎么做單元測試的？
面試官心理預期
面試官詢問單元測試并非僅僅想了解這一概念，背后可能考察面試者以下三個方面：
- 對軟件工程生命周期的熟悉程度，以及對測試階段各種方法（包括單元測試、集成測試、冒煙測試等）和其重要性的理解。
- 面試者是否展現出足夠的責任心，明白優秀的測試工作對自身代碼負責的重要性。
- 優秀的單元測試用例也體現了開發者在設計和編碼方面的基本素質。
基于以上三點，我們需要思考什么樣的單元測試才能被視為有效？
高手回答
整個軟件工程的生命周期大致分為以下階段：
- 需求分析階段：包括需求調研、設計和評審
- 設計階段：主要集中在架構設計
- 開發階段：正式開始編碼工作
- 測試階段：完成編碼后，包括：
自測：單元測試 -> 集成測試
提測：QA介入集成測試，進行多輪測試
- 發布階段：QA完成測試后，可以進行上線，其中包括：
- 預發布：部署到線上環境，QA進行回歸測試，逐步增加流量，觀察是否存在異常
- 正式上線：若預發布無問題，則代碼正式上線，根據灰度或A/B測試策略控制新功能流量比例，經過穩定運行一段時間無異常后，逐步放開全部流量。
我們再深入分析每個階段發現缺陷的成本，主要指從發現到解決問題所需的人力時間成本：
- 需求分析階段：如果設計評審發現不合理，可以選擇不執行，僅需花費幾個小時進行會議討論。
- 設計階段：架構設計也需要評審，同樣只需要幾個小時會議時間。
- 開發階段：如果前兩個階段沒有問題，小型功能修復通常需要幾小時，大型功能可能需要幾天甚至更長時間，可能導致開發出無效功能，需要重新設計和開發，帶來重復勞動的局面。
- 測試階段：無論是自測還是提測的集成測試，修復一個缺陷意味著重新部署代碼，對于大型項目，啟動時間可能是分鐘級。不論是自測還是提測，修復多個缺陷會阻塞測試進度，多次部署累計的時間成本非常高。而單元測試一個案例通常只需要毫秒或秒級，做好單元測試可以顯著提高效率。許多公司非常重視單元測試的覆蓋率和有效性，甚至將單元測試納入持續集成/持續交付流程，僅當所有單測通過才能部署。同時，QA團隊也極為關注阻塞測試進度的情況。
- 發布階段：通常經過QA嚴格測試后才進入發布階段，雖然不會出現明顯的缺陷，但也不能排除存在問題。某些缺陷可能在實際用戶請求或高流量時才會顯現，這些越過測試和預發布環境的問題可能會在線上直接暴露。灰度和A/B測試的部分目的是將線上問題造成的影響最小化。這也解釋了即使在各大互聯網公司，仍可能發生事故。這種情況不僅涉及時間成本，嚴重的缺陷可能帶來直接的經濟損失和用戶流失，一旦程序員出現問題，將成為談資。因此，許多公司非常重視缺陷漏測率，即測試階段未發現的問題。
上述內容提到了單元測試的關鍵要點，以下是編寫優質單元測試的方法總結：
如何編寫單元測試
- 單元測試代碼與正式代碼同等重要，需要清晰層次分明，命名符合實際場景，并且要有適當的注釋。可借鑒《代碼整潔之道》中的技巧，關鍵是要確保測試用例易于理解。
- 不要盲目地追求覆蓋率，而是要盡可能覆蓋所有可能的場景。
- 單元測試要保持可用性，納入持續集成/持續交付流程。如果所有測試用例不能通過，就不允許部署。
- 確保每次運行測試用例都是確定性的，不依賴外部變化和不確定因素，包括但不限于：
- 隨機事件：例如隨機數，最好使用模擬(Mock)進行控制；
- IO操作：無論是磁盤IO還是網絡IO（如數據庫、外部接口），都需要隔離，最好也進行模擬。
- 必須包含斷言，否則單元測試就失去了意義。不能只是簡單地打印結果，人工觀察，在運行所有測試用例時很少會花時間檢查每一個輸出。
- 驗證邊界情況和異常情況，這兩點經常被忽視。邊界條件可能包括：
- 傳入錯誤參數的反應；
- 依賴返回不正確結果的情況。
異常情況包括：
- 外部異常：依賴（內部或外部接口、數據庫環境等）拋出異常將如何處理；
- 內部異常：代碼本身拋出RuntimeException的后果。
- 正式業務代碼應該遵循單一職責原則，高內聚低耦合可使單元測試更簡單，測試粒度更細致，覆蓋率更高。每個方法或類應只負責一項任務，這樣測試用例只需關注當前方法的有效性，而不需要考慮方法之間的調用。每個測試用例也應只關注一件事情。
另一個優秀的策略是采用測試驅動開發（TDD）方法，即先列出所有可能的測試用例，然后再開始實現邏輯代碼。這種方式可以快速創建出完備的單元測試集合。值得注意的是，在國內很少有公司采用TDD開發模式。
領域驅動設計（DDD）強調明確的邊界劃分，事件風暴和防腐層的設計為測試驅動開發（TDD）和單元測試提供了良好的基礎。領域驅動設計（DDD）中倡導清晰的邊界劃分，通過事件風暴和防腐層設計，為TDD和單元測試提供了有力支持。
前文提到使用Mock對象來隔離I/O操作和隨機事件，當然，Mock也可以應用于各種依賴關系，比如Spring Bean之間的依賴、工具類、各種內部接口的依賴等。Mock的作用是模擬所依賴的資源，我們可以假定依賴操作是成功或失敗的，這樣測試只需關注自身代碼對依賴產生的響應結果即可。
Java的單元測試
Java工程也可以集成Spock框架進行單元測試，Spock使用Groovy語言編寫測試用例。由于Groovy是一種動態語言，非常靈活，非常適合編寫簡潔的單元測試代碼。同時，Spock不僅局限于模擬（Mock），還提供各種高效的功能（這些是傳統JUnit和Mockito無法實現的）：
- Spy：可以對部分資源進行模擬，方便地對同一類內相互調用的方法進行模擬和驗證。
- Mock：對依賴資源進行模擬，同時驗證依賴資源被調用的次數。例如，測試Redis寫功能時，可以模擬Redis客戶端，驗證傳入方法的參數是否符合預期，以及驗證Redis寫入方法被調用的次數。
- Stub：對依賴資源進行模擬返回一個結果，不關心調用次數或參數是否匹配預期。
- 可以直接忽略待驗證方法的成員封裝級別，可以直接測試私有聲明的方法和變量。
- 基于數據驅動的測試：借助where關鍵詞和數據表格的方式，在一個測試案例中驗證要測試的參數和期望返回值的所有可能情況。
- 可以方便地驗證拋出的異常。
- 與Spring集成方便：可以進行Spring框架的集成測試，包括對Spring MVC、Spring Boot的HTTP接口層進行單元測試，無需啟動Web容器。
所以編寫優秀的單元測試代碼是卓越程序員的基本修養。因為針對有用戶訪問和無用戶訪問的項目，相同的代碼甚至在極端用戶流量下可能帶來截然不同的效果。在面對極端用戶流量時，每次修改一行代碼上線都如履薄冰。懷著敬畏之心對待每一次上線和線上操作，至關重要。
