建站
咨詢
售后
建站咨詢
新聞中心
?大家好，我是樹哥！
創(chuàng)新互聯(lián)建站專注于讓胡路企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),商城建設(shè)。讓胡路網(wǎng)站建設(shè)公司,為讓胡路等地區(qū)提供建站服務(wù)。全流程定制制作，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)
工作了快 10 年了，跟研發(fā)小伙伴聊起單測，絕大多數(shù)人的反應(yīng)是 —— 單測沒啥用，寫單測就是為了應(yīng)付單測覆蓋率的 KPI 指標。恰好我最近在團隊落地單測相關(guān)的內(nèi)容，經(jīng)過一段時間的持續(xù)迭代，我對單測的看法也從一開始的 沒啥用? 到后面的 好像有點東西?，再到最后的 臥槽，真牛逼！。基本上隨著單測寫得越深入，我對單測就越發(fā)重視。
為啥說單測沒啥用？
那些說單測沒啥用的小伙伴，我想大概率是不知道怎么寫單測，沒寫過真正合格的單測，而只是用單測來湊湊單測覆蓋率的 KPI 指標。在這種情況下，單測當然沒啥用，因為它沒辦法幫你提高代碼質(zhì)量，幫你減少 bug。
試想一下，如果一個東西能幫你提升需求開發(fā)質(zhì)量，減少提測需求 bug 數(shù)量，那研發(fā)同學(xué)怎么可能不愿意去學(xué)習一下呢？
在我看來，單測一個很明顯的價值就是 —— 它能極大地減少你的需求 bug 數(shù)量，甚至一個 bug 都沒有！ 那為啥大家都會覺得單測沒用呢？我想問題可能是多方面的，其中可能的幾個原因是：
- 需求不明確，邊寫代碼邊改需求，這咋寫單測？
- 時間非常趕，業(yè)務(wù)代碼都寫不完，還寫單測？
- 不知道咋寫單測，于是隨便寫寫，發(fā)現(xiàn)好像沒啥用？
- 沒有選擇合適的單測框架，單測代碼寫的業(yè)務(wù)代碼還多，這可咋整？
- 等等
總而言之，這一切的原因?qū)е聸]寫出合格的單測，沒辦法讓單測為他們帶來好處，于是他們對單測充滿了失望，最終就覺得單測沒用。那怎么寫出合格的單測呢？這就是另外一個話題了，有機會我們再詳細聊聊。
單測到底有啥用？
聽我瞎扯了半天，有同學(xué)忍不住了：看你把單測吹得，那你說單測到底有啥用？
在我看來，單測除了顯著提升需求代碼質(zhì)量之外，還有下面幾個好處：
- 提升系統(tǒng)穩(wěn)定性
- 系統(tǒng)更加健壯
- 提升代碼編寫能力
- 有利于穩(wěn)定迭代
- 有利于深入了解技術(shù)與業(yè)務(wù)
提升系統(tǒng)穩(wěn)定性。 如果你每一個方法函數(shù)都經(jīng)過了測試，并且其分支覆蓋率都達到了較高水平，那么你很難寫出有問題的代碼，因為每種情況你都考慮到了。
在后續(xù)的迭代中，由于單測用例的存在，它就可以保證修改后的代碼不會影響到之前的業(yè)務(wù)邏輯。簡單來說，由于單測的存在，違背之前業(yè)務(wù)邏輯的代碼無法運行通過，因此提高了系統(tǒng)穩(wěn)定性。
系統(tǒng)更加健壯。 系統(tǒng)的健壯，其實是得通過分支覆蓋率來實現(xiàn)的。分支覆蓋率，其實就是每一種可能的情況你都考慮到了，那么系統(tǒng)會更加健壯。
舉一個很簡單的例子，有一個計算器類的除法函數(shù)，簡單的測試可能只會用正數(shù)進行測試，更進一步的可能會用負數(shù)，但是如果用 0 去測試呢？是否能成功呢？通過對分支覆蓋率的要求，使得我們考慮到更多異常情況，從而使得系統(tǒng)更加健壯。
提升代碼編寫能力。 當我們開始對單測覆蓋率和分支覆蓋率有要求，并且開始寫單測代碼之后，我們會被迫站在另一個視角去審視我們寫的代碼。如果我們的代碼寫得一點邏輯都沒有，那我們的單測會很難寫，那我們會忍不住去重寫它，這就間接地提升了我們的代碼編寫能力。
與代碼邏輯類似，代碼的結(jié)構(gòu)以及設(shè)計也會影響單測的編寫，寫單測可以讓我們重新審視自己寫的的代碼，從而間接提升我們的代碼編寫能力。
有利于穩(wěn)定迭代。 如果你寫的代碼質(zhì)量很高，只有非常少的 bug，甚至一個 bug 都沒有。那么測你需求的測試肯定很開心，因為直接一把過呀！從項目管理層面來看，如果每個人都能做到這樣的程度，那么項目的迭代是非常穩(wěn)定、并且高效的！
有利于深入了解技術(shù)與業(yè)務(wù)。 當我們寫單測的時候，我們必須去了解某個東西是怎么運行的。如果你沒有了解清楚某塊業(yè)務(wù)，就開始去修改這塊業(yè)務(wù)的代碼，那之前的單測用例會教你做人，頻頻報錯的單測信息會讓你寸步難行。
單測用例的存在讓你必須弄清楚這塊業(yè)務(wù)的邏輯，才可以寫新的業(yè)務(wù)邏輯，這間接促進了我們對于業(yè)務(wù)的了解。此外，我們寫單測的時候經(jīng)常會進行 Stub 和 Mock，這會要求你必須弄清楚項目中用到的技術(shù)原理，不然你無法成功編寫單測代碼，這也同樣間接促進你去了解項目中用到的技術(shù)。
單測不是銀彈
說了這么多，可能有些小伙伴覺得我是單測的死忠粉。但我想說的是：單測也不是銀彈！
在我看來，單測只能解決一類問題，那就是 —— 你覺得你寫對了，但是你沒寫對的問題。 對于那些你本來就不知道，或者說代碼里根本就沒寫的東西，單測是無能為力的。舉個很簡單的幾個例子：
- 提測提了一個 bug，你排查之后發(fā)現(xiàn)有某個業(yè)務(wù)細節(jié)你沒考慮到，從而觸發(fā)了這個 bug。由于你本來就沒考慮到，因此代碼里也沒有做對應(yīng)的處理，那么單測肯定也解決不了這個問題。
- 由于產(chǎn)品對需求沒有寫清楚，于是在測試階段不斷補需求細節(jié)，于是你也不斷地修修改改，于是越改 bug 越多。
除此之外，寫單測也確實是會費一些時間，特別是對于剛剛寫單測的同學(xué)來說。如果一個項目非常緊張，需求也不確定，經(jīng)常邊寫代碼邊改需求，這時候再要求單測覆蓋率，可能不太現(xiàn)實。
單測的適用場景
看了這么多，知道了單測有那么多好處，但又單測又不能包治百病，那單測到底適合在什么場景使用呢？在我看來，對于是否要推行單測，以及單測的要求高低，其實取決于下面幾個維度：
- 代碼復(fù)用率。代碼復(fù)用率越高，越有必要推行單測，越有必要提升單測的要求。因此這些代碼被很多業(yè)務(wù)引用，因此其一旦有問題便會影響很多業(yè)務(wù)方，在這樣的代碼推行單測是收益較高的。
- 業(yè)務(wù)變化率。業(yè)務(wù)變化越快，越不適合用單測。如果業(yè)務(wù)變化非?？欤粋€單測的內(nèi)容上線了沒幾天就又要修改，那么你不僅僅需要修改業(yè)務(wù)代碼，還需要修改單測代碼，那就是雙倍的工作量了。
- 人員變化率。人員變化率指的是某個模塊負責人的變化情況。如果某個模塊的負責人經(jīng)常變來變?nèi)?，那么也是不太適合推行單測的。因為新負責的人需要花大量的時間去熟悉單測的內(nèi)容，這會導(dǎo)致需求開發(fā)的時間變得非常長。
- 業(yè)務(wù)重要性。越是核心的業(yè)務(wù)，越有必要推行單測，并且越有必要以高標準要求。因為核心業(yè)務(wù)的穩(wěn)定性、健壯性對于公司來說肯定非常重要，而單測確實是能夠在最小單元去提升系統(tǒng)穩(wěn)定性和系統(tǒng)健壯性。
上面提到的 4 個衡量維度，我們不能單一地去看待，而是要根據(jù)實際情況去綜合判斷。例如某個業(yè)務(wù)的人員變化就是很頻繁，那就一定不適合推行單測嗎？
其實并不是，而是說對于人員變化非常頻繁的業(yè)務(wù)，其推行單測成本會很高。但如果這塊業(yè)務(wù)就是非常重要，但他的人員變化就是很頻繁，那強制以高標準的單測要求確實可以提高系統(tǒng)健壯性和系統(tǒng)穩(wěn)定性，但是代價就是研發(fā)時間很長。如果產(chǎn)研團隊能夠接受這個結(jié)果，那么這么做就是合理的。
總的來看，是否推行單測以及推行單測的標準高低，需要我們根據(jù)上面幾個維度去綜合考量，得出一個最適合的標準！?
網(wǎng)頁標題：單測無用論，這是真的嗎？
當前網(wǎng)址：http://m.fisionsoft.com.cn/article/dphhoic.html
