你平時(shí)是怎么做單元測(cè)試的？

面試官心理預(yù)期

面試官詢問(wèn)單元測(cè)試并非僅僅想了解這一概念，背后可能考察面試者以下三個(gè)方面：

1. 對(duì)軟件工程生命周期的熟悉程度，以及對(duì)測(cè)試階段各種方法（包括單元測(cè)試、集成測(cè)試、冒煙測(cè)試等）和其重要性的理解。
2. 面試者是否展現(xiàn)出足夠的責(zé)任心，明白優(yōu)秀的測(cè)試工作對(duì)自身代碼負(fù)責(zé)的重要性。
3. 優(yōu)秀的單元測(cè)試用例也體現(xiàn)了開(kāi)發(fā)者在設(shè)計(jì)和編碼方面的基本素質(zhì)。

基于以上三點(diǎn)，我們需要思考什么樣的單元測(cè)試才能被視為有效？

高手回答

整個(gè)軟件工程的生命周期大致分為以下階段：

• 需求分析階段：包括需求調(diào)研、設(shè)計(jì)和評(píng)審
• 設(shè)計(jì)階段：主要集中在架構(gòu)設(shè)計(jì)
• 開(kāi)發(fā)階段：正式開(kāi)始編碼工作
• 測(cè)試階段：完成編碼后，包括：

自測(cè)：?jiǎn)卧獪y(cè)試 -> 集成測(cè)試

提測(cè)：QA介入集成測(cè)試，進(jìn)行多輪測(cè)試

• 發(fā)布階段：QA完成測(cè)試后，可以進(jìn)行上線，其中包括：
• 預(yù)發(fā)布：部署到線上環(huán)境，QA進(jìn)行回歸測(cè)試，逐步增加流量，觀察是否存在異常
• 正式上線：若預(yù)發(fā)布無(wú)問(wèn)題，則代碼正式上線，根據(jù)灰度或A/B測(cè)試策略控制新功能流量比例，經(jīng)過(guò)穩(wěn)定運(yùn)行一段時(shí)間無(wú)異常后，逐步放開(kāi)全部流量。

我們?cè)偕钊敕治雒總€(gè)階段發(fā)現(xiàn)缺陷的成本，主要指從發(fā)現(xiàn)到解決問(wèn)題所需的人力時(shí)間成本：

• 需求分析階段：如果設(shè)計(jì)評(píng)審發(fā)現(xiàn)不合理，可以選擇不執(zhí)行，僅需花費(fèi)幾個(gè)小時(shí)進(jìn)行會(huì)議討論。
• 設(shè)計(jì)階段：架構(gòu)設(shè)計(jì)也需要評(píng)審，同樣只需要幾個(gè)小時(shí)會(huì)議時(shí)間。
• 開(kāi)發(fā)階段：如果前兩個(gè)階段沒(méi)有問(wèn)題，小型功能修復(fù)通常需要幾小時(shí)，大型功能可能需要幾天甚至更長(zhǎng)時(shí)間，可能導(dǎo)致開(kāi)發(fā)出無(wú)效功能，需要重新設(shè)計(jì)和開(kāi)發(fā)，帶來(lái)重復(fù)勞動(dòng)的局面。
• 測(cè)試階段：無(wú)論是自測(cè)還是提測(cè)的集成測(cè)試，修復(fù)一個(gè)缺陷意味著重新部署代碼，對(duì)于大型項(xiàng)目，啟動(dòng)時(shí)間可能是分鐘級(jí)。不論是自測(cè)還是提測(cè)，修復(fù)多個(gè)缺陷會(huì)阻塞測(cè)試進(jìn)度，多次部署累計(jì)的時(shí)間成本非常高。而單元測(cè)試一個(gè)案例通常只需要毫秒或秒級(jí)，做好單元測(cè)試可以顯著提高效率。許多公司非常重視單元測(cè)試的覆蓋率和有效性，甚至將單元測(cè)試納入持續(xù)集成/持續(xù)交付流程，僅當(dāng)所有單測(cè)通過(guò)才能部署。同時(shí)，QA團(tuán)隊(duì)也極為關(guān)注阻塞測(cè)試進(jìn)度的情況。
• 發(fā)布階段：通常經(jīng)過(guò)QA嚴(yán)格測(cè)試后才進(jìn)入發(fā)布階段，雖然不會(huì)出現(xiàn)明顯的缺陷，但也不能排除存在問(wèn)題。某些缺陷可能在實(shí)際用戶請(qǐng)求或高流量時(shí)才會(huì)顯現(xiàn)，這些越過(guò)測(cè)試和預(yù)發(fā)布環(huán)境的問(wèn)題可能會(huì)在線上直接暴露。灰度和A/B測(cè)試的部分目的是將線上問(wèn)題造成的影響最小化。這也解釋了即使在各大互聯(lián)網(wǎng)公司，仍可能發(fā)生事故。這種情況不僅涉及時(shí)間成本，嚴(yán)重的缺陷可能帶來(lái)直接的經(jīng)濟(jì)損失和用戶流失，一旦程序員出現(xiàn)問(wèn)題，將成為談資。因此，許多公司非常重視缺陷漏測(cè)率，即測(cè)試階段未發(fā)現(xiàn)的問(wèn)題。

上述內(nèi)容提到了單元測(cè)試的關(guān)鍵要點(diǎn)，以下是編寫(xiě)優(yōu)質(zhì)單元測(cè)試的方法總結(jié)：

如何編寫(xiě)單元測(cè)試

1. 單元測(cè)試代碼與正式代碼同等重要，需要清晰層次分明，命名符合實(shí)際場(chǎng)景，并且要有適當(dāng)?shù)淖⑨?。可借鑒《代碼整潔之道》中的技巧，關(guān)鍵是要確保測(cè)試用例易于理解。
2. 不要盲目地追求覆蓋率，而是要盡可能覆蓋所有可能的場(chǎng)景。
3. 單元測(cè)試要保持可用性，納入持續(xù)集成/持續(xù)交付流程。如果所有測(cè)試用例不能通過(guò)，就不允許部署。
4. 確保每次運(yùn)行測(cè)試用例都是確定性的，不依賴外部變化和不確定因素，包括但不限于：

• 隨機(jī)事件：例如隨機(jī)數(shù)，最好使用模擬(Mock)進(jìn)行控制；
• IO操作：無(wú)論是磁盤(pán)IO還是網(wǎng)絡(luò)IO（如數(shù)據(jù)庫(kù)、外部接口），都需要隔離，最好也進(jìn)行模擬。

5. 必須包含斷言，否則單元測(cè)試就失去了意義。不能只是簡(jiǎn)單地打印結(jié)果，人工觀察，在運(yùn)行所有測(cè)試用例時(shí)很少會(huì)花時(shí)間檢查每一個(gè)輸出。
6. 驗(yàn)證邊界情況和異常情況，這兩點(diǎn)經(jīng)常被忽視。邊界條件可能包括：

• 傳入錯(cuò)誤參數(shù)的反應(yīng)；
• 依賴返回不正確結(jié)果的情況。

異常情況包括：

• 外部異常：依賴（內(nèi)部或外部接口、數(shù)據(jù)庫(kù)環(huán)境等）拋出異常將如何處理；
• 內(nèi)部異常：代碼本身拋出RuntimeException的后果。

7. 正式業(yè)務(wù)代碼應(yīng)該遵循單一職責(zé)原則，高內(nèi)聚低耦合可使單元測(cè)試更簡(jiǎn)單，測(cè)試粒度更細(xì)致，覆蓋率更高。每個(gè)方法或類應(yīng)只負(fù)責(zé)一項(xiàng)任務(wù)，這樣測(cè)試用例只需關(guān)注當(dāng)前方法的有效性，而不需要考慮方法之間的調(diào)用。每個(gè)測(cè)試用例也應(yīng)只關(guān)注一件事情。

另一個(gè)優(yōu)秀的策略是采用測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）方法，即先列出所有可能的測(cè)試用例，然后再開(kāi)始實(shí)現(xiàn)邏輯代碼。這種方式可以快速創(chuàng)建出完備的單元測(cè)試集合。值得注意的是，在國(guó)內(nèi)很少有公司采用TDD開(kāi)發(fā)模式。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）強(qiáng)調(diào)明確的邊界劃分，事件風(fēng)暴和防腐層的設(shè)計(jì)為測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）和單元測(cè)試提供了良好的基礎(chǔ)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）中倡導(dǎo)清晰的邊界劃分，通過(guò)事件風(fēng)暴和防腐層設(shè)計(jì)，為T(mén)DD和單元測(cè)試提供了有力支持。

前文提到使用Mock對(duì)象來(lái)隔離I/O操作和隨機(jī)事件，當(dāng)然，Mock也可以應(yīng)用于各種依賴關(guān)系，比如Spring Bean之間的依賴、工具類、各種內(nèi)部接口的依賴等。Mock的作用是模擬所依賴的資源，我們可以假定依賴操作是成功或失敗的，這樣測(cè)試只需關(guān)注自身代碼對(duì)依賴產(chǎn)生的響應(yīng)結(jié)果即可。

Java的單元測(cè)試

Java工程也可以集成Spock框架進(jìn)行單元測(cè)試，Spock使用Groovy語(yǔ)言編寫(xiě)測(cè)試用例。由于Groovy是一種動(dòng)態(tài)語(yǔ)言，非常靈活，非常適合編寫(xiě)簡(jiǎn)潔的單元測(cè)試代碼。同時(shí)，Spock不僅局限于模擬（Mock），還提供各種高效的功能（這些是傳統(tǒng)JUnit和Mockito無(wú)法實(shí)現(xiàn)的）：

1. Spy：可以對(duì)部分資源進(jìn)行模擬，方便地對(duì)同一類內(nèi)相互調(diào)用的方法進(jìn)行模擬和驗(yàn)證。
2. Mock：對(duì)依賴資源進(jìn)行模擬，同時(shí)驗(yàn)證依賴資源被調(diào)用的次數(shù)。例如，測(cè)試Redis寫(xiě)功能時(shí)，可以模擬Redis客戶端，驗(yàn)證傳入方法的參數(shù)是否符合預(yù)期，以及驗(yàn)證Redis寫(xiě)入方法被調(diào)用的次數(shù)。
3. Stub：對(duì)依賴資源進(jìn)行模擬返回一個(gè)結(jié)果，不關(guān)心調(diào)用次數(shù)或參數(shù)是否匹配預(yù)期。
4. 可以直接忽略待驗(yàn)證方法的成員封裝級(jí)別，可以直接測(cè)試私有聲明的方法和變量。
5. 基于數(shù)據(jù)驅(qū)動(dòng)的測(cè)試：借助where關(guān)鍵詞和數(shù)據(jù)表格的方式，在一個(gè)測(cè)試案例中驗(yàn)證要測(cè)試的參數(shù)和期望返回值的所有可能情況。
6. 可以方便地驗(yàn)證拋出的異常。
7. 與Spring集成方便：可以進(jìn)行Spring框架的集成測(cè)試，包括對(duì)Spring MVC、Spring Boot的HTTP接口層進(jìn)行單元測(cè)試，無(wú)需啟動(dòng)Web容器。

所以編寫(xiě)優(yōu)秀的單元測(cè)試代碼是卓越程序員的基本修養(yǎng)。因?yàn)獒槍?duì)有用戶訪問(wèn)和無(wú)用戶訪問(wèn)的項(xiàng)目，相同的代碼甚至在極端用戶流量下可能帶來(lái)截然不同的效果。在面對(duì)極端用戶流量時(shí)，每次修改一行代碼上線都如履薄冰。懷著敬畏之心對(duì)待每一次上線和線上操作，至關(guān)重要。