你真的需要單元測(cè)試嗎-

第第頁(yè)你真的需要單元測(cè)試嗎?你真的需要單元測(cè)試嗎?

發(fā)表于：2023-04-16來(lái)源：簡(jiǎn)書(shū)：戎碼半生點(diǎn)擊數(shù)：標(biāo)簽：?jiǎn)卧獪y(cè)試

博主最近在接觸一些Android單元測(cè)試方面的工作，發(fā)現(xiàn)自己并沒(méi)有體會(huì)到大多數(shù)文章所宣傳的“單元測(cè)試會(huì)帶來(lái)工作效率的巨大提升”之類的諸多好處，于是本著批判與自我批判的精神對(duì)

博主最近在接觸一些Android單元（測(cè)試）方面的工作，發(fā)現(xiàn)自己并沒(méi)有體會(huì)到大多數(shù)文章所宣傳的"單元（測(cè)試）會(huì)帶來(lái)工作效率的巨大提升'之類的諸多好處，于是本著批判與自我批判的精神對(duì)（單元測(cè)試）做了一番研究，以下言論僅代表個(gè)人觀點(diǎn)，如果不足，歡迎指教。

單元測(cè)試不是用來(lái)找Bug的當(dāng)你看到網(wǎng)上諸多關(guān)于單元測(cè)試的贊美時(shí)，仔細(xì)看看你就會(huì)發(fā)現(xiàn)很多說(shuō)的其實(shí)是TDD(Test-DrivenDevelopment，測(cè)試驅(qū)動(dòng)（開(kāi)發(fā)）)，不幸的是大多數(shù)人并沒(méi)有注意區(qū)分這兩個(gè)概念。在WritingGreatUnitTests:BestandWorstPractices中，StevenSanderson強(qiáng)烈表達(dá)了自己的觀點(diǎn)：Unittestingisnotaboutfinding（bug）s。簡(jiǎn)單來(lái)說(shuō)，當(dāng)先寫(xiě)代碼后寫(xiě)單元測(cè)試的時(shí)候，單元測(cè)試就成了一種發(fā)現(xiàn)Bug的手段，但根據(jù)其幾十年的開(kāi)發(fā)經(jīng)驗(yàn)指出這種手段其實(shí)是十分低效的，因?yàn)榧词姑總€(gè)功能模塊都能正常工作，但是仍然不能保證模塊之間、模塊與用戶環(huán)境之間能正確交互，而后者往往是Bug的主要來(lái)源。單元測(cè)試或許能找到一些Bug，但相比集成測(cè)試和（系統(tǒng)測(cè)試）就顯得十分低效了。

既然如此，那么單元測(cè)試為何又備受追捧呢？在HowGoogleTestsSoftware中，三位谷歌的專家介紹了谷歌的（軟件測(cè)試）之道，總而言之就是谷歌會(huì)在開(kāi)發(fā)之初設(shè)計(jì)好單元測(cè)試（其實(shí)是用代碼表達(dá)（需求）），在開(kāi)發(fā)中不斷迭代以通過(guò)全部的測(cè)試（其實(shí)是完成全部（需求）），最終交付給（測(cè)試人員）的軟件已經(jīng)經(jīng)過(guò)一輪測(cè)試，如果還有集成后的Bug，就可以交給專業(yè)的（測(cè)試人員）發(fā)現(xiàn)了。這是一種典型的敏捷開(kāi)發(fā)，可以看到單元測(cè)試扮演更多的是驅(qū)動(dòng)開(kāi)發(fā)的角色。

作為技術(shù)標(biāo)桿的谷歌已經(jīng)全面引入了單元測(cè)試，那么我作為一個(gè)普通開(kāi)發(fā)者為什么還要提出一番質(zhì)疑呢？請(qǐng)看下一節(jié)。

單元測(cè)試的邊際收益在經(jīng)濟(jì)學(xué)領(lǐng)域，有一個(gè)著名的邊際收益遞減規(guī)律，指在投入生產(chǎn)要素后，每單位生產(chǎn)要素所能提供的產(chǎn)量增加發(fā)生遞減（二階導(dǎo)數(shù)為負(fù)）的現(xiàn)象。在本文討論的場(chǎng)景中，投入產(chǎn)出如下（引自：軟件開(kāi)發(fā)過(guò)程中值不值得寫(xiě)單元測(cè)試？-voidintsblog）：

成本(投入)

編寫(xiě)單元（測(cè)試（用例））所額外付出的時(shí)間，短期內(nèi)會(huì)拖慢項(xiàng)目進(jìn)度。收益(產(chǎn)出)

提升代碼質(zhì)量。監(jiān)督開(kāi)發(fā)人員寫(xiě)出更加易于測(cè)試和可維護(hù)的代碼。提升開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部的協(xié)作效率。其他開(kāi)發(fā)人員可以通過(guò)閱讀單元測(cè)試用例來(lái)理解代碼原的意圖。保證功能實(shí)現(xiàn)的長(zhǎng)期穩(wěn)定。代碼一旦發(fā)生與原功能意圖不相符的變化，通過(guò)跑單元測(cè)試可以體現(xiàn)出來(lái)，即可以防止功能被無(wú)意識(shí)地破壞。提高（自動(dòng)化）測(cè)試占比，降低其他測(cè)試方式上的投入。在經(jīng)濟(jì)學(xué)中，邊際收益遞減現(xiàn)象常出現(xiàn)于產(chǎn)量的短期分析中。結(jié)合對(duì)同事的咨詢以及自己的調(diào)研，這個(gè)現(xiàn)象在軟件開(kāi)發(fā)領(lǐng)域同樣適用。當(dāng)我們需要寫(xiě)原型或者開(kāi)發(fā)一個(gè)短期緊急需求的時(shí)候，（產(chǎn)品、運(yùn)營(yíng)人員）往往要求快速交付，并且由于代碼規(guī)模有限也往往不會(huì)有太多Bug，在這種短期開(kāi)發(fā)中如果引入單元測(cè)試往往會(huì)適得其反，投入了雙倍的時(shí)間卻沒(méi)有明顯的附加收益。而分析HowGoogleTestsSoftware一書(shū)中最多提及的幾個(gè)項(xiàng)目（Chrome,Android,Gmail）可以發(fā)現(xiàn)，單元測(cè)試（更準(zhǔn)確說(shuō)是Test-DrivenDevelopment）的成功案例往往都是一些架構(gòu)設(shè)計(jì)良好，處于長(zhǎng)期迭代開(kāi)發(fā)，基本沒(méi)有短期臨時(shí)緊急需求的產(chǎn)品，項(xiàng)目初期的單元測(cè)試往往在幾年后還能使用，復(fù)用率極高（私以為復(fù)用率某種程度上可以作為是否值得引入單元測(cè)試的標(biāo)準(zhǔn)）。而如果一個(gè)項(xiàng)目一開(kāi)始沒(méi)有引入單元測(cè)試、過(guò)時(shí)和糟糕的代碼沒(méi)有及時(shí)重構(gòu)、臨時(shí)短期需求偏多，往往就沒(méi)有引入單元測(cè)試的必要了。

JakeWharton也頭疼的單元測(cè)試JakeWharton何許人也?答：諸多著名（開(kāi)源）項(xiàng)目的，Android社區(qū)的旗幟人物：

[圖