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