在前面一篇文章（單測無用論，這是真的嗎？）中，我提到判斷單測是否適用的幾個(gè)維度，其中有一個(gè)就是業(yè)務(wù)變化情況。理論上來說，業(yè)務(wù)變化快，改單測成本高，維護(hù)成本也高。按理說，如果不是對功能質(zhì)量有很高的要求，感覺是可以不寫單測的。

但事實(shí)真的是這樣嗎？針對這個(gè)問題，我與單測群的小伙伴們進(jìn)行了討論，大家都非常積極地發(fā)表了看法。從投票結(jié)果來看，有 50% 的人覺得沒必要，有 50% 的人覺得有必要。

筆者一開始是覺得可以不寫的。畢竟如果一個(gè)業(yè)務(wù)經(jīng)常變化，那么你就要不斷地去調(diào)整單測的內(nèi)容，這樣勢必會(huì)增加研發(fā)成本，最后造成研發(fā)交付周期變長。從群里小伙伴的投票來看，應(yīng)該有不少小伙伴跟我持同樣的看法。

但是當(dāng)我深入去思考這個(gè)問題時(shí)，我卻得出了完全不同的結(jié)論 —— 即使業(yè)務(wù)變化快，也需要堅(jiān)持寫單測！

站在整個(gè)軟件產(chǎn)品來說，兩個(gè)非常重要的維度是：交付速度和交付質(zhì)量。就如我上面所說：我們不寫單測的原因，是因?yàn)閱螠y會(huì)拉長交付周期，使得交付速度變慢。但如果交付速度提高了，可是交付質(zhì)量下降了，可以接受嗎？

我想，對于有些規(guī)模的公司來說，交付質(zhì)量一定比交付速度更重要。而對于一些小微或者創(chuàng)新業(yè)務(wù)來說，可能交付質(zhì)量可以沒那么重要，但是也不能太過于拉垮。因此，是否寫單測這個(gè)問題，本質(zhì)上是交付速度和交付質(zhì)量哪個(gè)更重要的問題。

但我們要知道 —— 上面的分析其實(shí)是站在整個(gè)產(chǎn)品（老板）的角度去思考問題的。如果我們站在編程者的角度看，你現(xiàn)在不寫單測，很可能只是把現(xiàn)在寫單測的時(shí)間挪到后面修 bug 而已。

除非你的代碼質(zhì)量真的很高，高到及時(shí)不寫單測一個(gè) bug 都沒有，那確實(shí)沒必要寫單測了。不然就如群友所說 —— 「前面埋下的雷，總會(huì)炸到修 Bug 的人」、「流程越往后，排查和修復(fù) bug 的成本會(huì)急劇增加！」。

除此之外，寫單測不僅僅能降低你的 bug 數(shù)量，它還能讓你考慮邏輯更加全面，讓你寫代碼的時(shí)候?qū)Ω鱾€(gè)異常、特殊分支都考慮到位。這其實(shí)是一種習(xí)慣，它會(huì)持續(xù)地讓你迭代優(yōu)化自己的代碼質(zhì)量，從而讓你不斷提升。

從覺得單測沒啥用，到覺得單測還有點(diǎn)用，再到業(yè)務(wù)變化不大可以寫寫單測，最后到即使業(yè)務(wù)變化快也要寫單測，深感單測寫得越多，越能感覺到單測的好處。?