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

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

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

但是當我深入去思考這個問題時，我卻得出了完全不同的結論 —— 即使業務變化快，也需要堅持寫單測！

站在整個軟件產品來說，兩個非常重要的維度是：交付速度和交付質量。就如我上面所說：我們不寫單測的原因，是因為單測會拉長交付周期，使得交付速度變慢。但如果交付速度提高了，可是交付質量下降了，可以接受嗎？

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

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

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

除此之外，寫單測不僅僅能降低你的 bug 數量，它還能讓你考慮邏輯更加全面，讓你寫代碼的時候對各個異常、特殊分支都考慮到位。這其實是一種習慣，它會持續地讓你迭代優化自己的代碼質量，從而讓你不斷提升。

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