在前面一篇文章（單測無用論，這是真的嗎？）中，我提到判斷單測是否適用的幾個維度，其中有一個就是業務變化情況。理論上來說，業務變化快，改單測成本高，維護成本也高。按理說，如果不是對功能質量有很高的要求，感覺是可以不寫單測的。
但事實真的是這樣嗎？針對這個問題，我與單測羣的小夥伴們進行了討論，大家都非常積極地發表了看法。從投票結果來看，有 50% 的人覺得沒必要，有 50% 的人覺得有必要。
筆者一開始是覺得可以不寫的。畢竟如果一個業務經常變化，那麼你就要不斷地去調整單測的內容，這樣勢必會增加研發成本，最後造成研發交付週期變長。從羣裏小夥伴的投票來看，應該有不少小夥伴跟我持同樣的看法。
但是當我深入去思考這個問題時，我卻得出了完全不同的結論 —— 即使業務變化快，也需要堅持寫單測！
站在整個軟件產品來說，兩個非常重要的維度是：交付速度和交付質量。就如我上面所說：我們不寫單測的原因，是因爲單測會拉長交付週期，使得交付速度變慢。但如果交付速度提高了，可是交付質量下降了，可以接受嗎？
我想，對於有些規模的公司來說，交付質量一定比交付速度更重要。而對於一些小微或者創新業務來說，可能交付質量可以沒那麼重要，但是也不能太過於拉垮。因此，是否寫單測這個問題，本質上是交付速度和交付質量哪個更重要的問題。
但我們要知道 —— 上面的分析其實是站在整個產品（老闆）的角度去思考問題的。如果我們站在編程者的角度看，你現在不寫單測，很可能只是把現在寫單測的時間挪到後面修 bug 而已。
除非你的代碼質量真的很高，高到及時不寫單測一個 bug 都沒有，那確實沒必要寫單測了。不然就如羣友所說 —— 「前面埋下的雷，總會炸到修 Bug 的人」、「流程越往後，排查和修復 bug 的成本會急劇增加！」。
除此之外，寫單測不僅僅能降低你的 bug 數量，它還能讓你考慮邏輯更加全面，讓你寫代碼的時候對各個異常、特殊分支都考慮到位。這其實是一種習慣，它會持續地讓你迭代優化自己的代碼質量，從而讓你不斷提升。
從覺得單測沒啥用，到覺得單測還有點用，再到業務變化不大可以寫寫單測，最後到即使業務變化快也要寫單測，深感單測寫得越多，越能感覺到單測的好處。
所以，對於筆者來說，我現在堅定認爲 —— 業務變化快，也有必要寫單測！不知道你們怎麼看這個問題，歡迎在評論區留言與大家討論~
對了，如果你對單測感興趣，希望進一步瞭解單測相關內容，希望與更多小夥伴交流討論。歡迎通過公衆號後臺加我微信（備註「單測交流」），我將拉你入羣，與 200 多小夥伴一起精進單測、提升代碼質量！