一、前言

半年前在公司團(tuán)隊(duì)內(nèi)推動(dòng)單元測試的落地，略有一些心得，記錄在此。如有不同觀點(diǎn)或建議，請(qǐng)?jiān)谠u(píng)論區(qū)留言，一起探討。

定義：單元測試是用來對(duì)一個(gè)模塊、一個(gè)函數(shù)或者一個(gè)類來進(jìn)行正確性檢驗(yàn)的測試工作。

單元測試從長期來看，可以提高代碼質(zhì)量，減少維護(hù)成本，降低重構(gòu)難度。但是從短期來看，加大了工作量，對(duì)于進(jìn)度緊張的項(xiàng)目中的開發(fā)人員來說，可能會(huì)成為不少的負(fù)擔(dān)。

本文從為什么要寫單元測試，何時(shí)寫，寫多細(xì)這些我們最關(guān)心的問題展開討論，試圖解答如何在進(jìn)度緊張的項(xiàng)目中，通過寫有效的單元測試來提高代碼質(zhì)量的問題。

二、單元測試要寫多細(xì)

酷殼上有篇關(guān)于“單元測試要做多細(xì)”的文章，文章是從StackOverflow上的一個(gè)問題討論開的。這個(gè)問題是–

“TDD需要花時(shí)間寫測試，而我們一般多少會(huì)寫一些代碼，而第一個(gè)測試是測試我的構(gòu)造函數(shù)有沒有把這個(gè)類的變量都設(shè)置對(duì)了，這會(huì)不會(huì)太過分了？ 那么，我們寫單元測試的這個(gè)單元的粒度到底是什么樣的？并且，是不是我們的測試測試得多了點(diǎn)？”

點(diǎn)贊最多的答案是–

老板為我的代碼付報(bào)酬，而不是測試，所以，我對(duì)此的價(jià)值觀是——測試越少越好，少到你對(duì)你的代碼質(zhì)量達(dá)到了某種自信（我覺得這種的自信標(biāo)準(zhǔn)應(yīng)該要高于業(yè)內(nèi)的標(biāo)準(zhǔn)，當(dāng)然，這種自信也可能是種自大）。如果我的編碼生涯中不會(huì)犯這種典型的錯(cuò)誤（如：在構(gòu)造函數(shù)中設(shè)了個(gè)錯(cuò)誤的值），那我就不會(huì)測試它。我傾向于去對(duì)那些有意義的錯(cuò)誤做測試，所以，我對(duì)一些比較復(fù)雜的條件邏輯會(huì)異常地小心。當(dāng)在一個(gè)團(tuán)隊(duì)中，我會(huì)非常小心的測試那些會(huì)讓團(tuán)隊(duì)容易出錯(cuò)的代碼。

這個(gè)答案給人感覺對(duì)單元測試持一定的否定態(tài)度和不感冒態(tài)度，但是這一最佳答案的回答者是Kent Beck！正是那位極限編程、測試驅(qū)動(dòng)開發(fā)和單元測試以及JUnit的創(chuàng)造者Kent Beck。Kent Beck的答案，正好回答了單元測試要寫到什么程度這個(gè)問題。單元測試不是越多越好，而是越有效越好！進(jìn)一步解讀就是哪些代碼需要有單元測試覆蓋：
1. 邏輯復(fù)雜的
2. 容易出錯(cuò)的
3. 不易理解的，即使是自己過段時(shí)間也會(huì)遺忘的，看不懂自己的代碼，單元測試代碼有助于理解代碼的功能和需求
4. 公共代碼。比如自定義的所有http請(qǐng)求都會(huì)經(jīng)過的攔截器；工具類等。
5. 核心業(yè)務(wù)代碼。一個(gè)產(chǎn)品里最核心最有業(yè)務(wù)價(jià)值的代碼應(yīng)該要有較高的單元測試覆蓋率。

三、何時(shí)寫單元測試

寫單元測試的時(shí)機(jī)不外乎三種情況：

（1）一是在具體實(shí)現(xiàn)代碼之前，這是測試驅(qū)動(dòng)開發(fā)（TDD）所提倡的；

（2）二是與具體實(shí)現(xiàn)代碼同步進(jìn)行。先寫少量功能代碼，緊接著寫單元測試（重復(fù)這兩個(gè)過程，直到完成功能代碼開發(fā)）。其實(shí)這種方案跟第一種已經(jīng)很接近，基本上功能代碼開發(fā)完，單元測試也差不多完成了。

（3）三是編寫完功能代碼再寫單元測試。我的實(shí)踐經(jīng)驗(yàn)告訴我，事后編寫的單元測試“粒度”都比較粗。對(duì)同樣的功能代碼，采取前兩種方案的結(jié)果可能是用10個(gè)“小”的單測來覆蓋，每個(gè)單測比較簡單易懂，可讀性可維護(hù)性都比較好（重構(gòu)時(shí)單測的改動(dòng)不大）；而第三種方案寫的單測，往往是用1個(gè)“大”的單測來覆蓋，這個(gè)單測邏輯就比較復(fù)雜，因?yàn)樗獪y的東西很多，可讀性可維護(hù)性就比較差。

建議：我個(gè)人是比較推薦單元測試與具體實(shí)現(xiàn)代碼同步進(jìn)行這個(gè)方案的。只有對(duì)需求有一定的理解后才能知道什么是代碼的正確性，才能寫出有效的單元測試來驗(yàn)證正確性，而能寫出一些功能代碼則說明對(duì)需求有一定理解了。

四、為什么要寫單元測試

這其實(shí)是問單元測試能帶來什么好處。之所以把這個(gè)問題放在最后討論是因?yàn)槿绻簧蟻砭驼f單元測試多好多好，終究還是會(huì)缺乏說服力。

而有了上面討論做鋪墊，我們更加清楚單元測試的使用場景，以及它做得到和做不到的。

單元測試的作用：

（1）讓我們對(duì)自己的代碼有信心

修改了代碼后單測依然通過的，起碼說明我們的修改沒有破壞程序的正確性。這從主觀上能增加我們對(duì)代碼的信心。雖然單元測試通過了并不意味著程序就沒有bug了，但我們也要了解到這可能不是單元測試的問題。單元測試顧名思義是測試一個(gè)”單元”，這個(gè)”單元”一般是類或方法，而不是整個(gè)系統(tǒng)。對(duì)整個(gè)系統(tǒng)的測試那是集成測試，功能測試的職責(zé)。單元測試追求的是快速反饋，頻繁執(zhí)行。集成測試雖然測“全局”，但成本較高，所以執(zhí)行頻率較少。兩者使用場景不同，目的不同。

（2）為代碼重構(gòu)保駕護(hù)航

看到代碼很差勁，想重構(gòu)，但又擔(dān)心重構(gòu)之后出問題，怎么辦呢？如果有單元測試情況就不一樣了，重構(gòu)完代碼，跑一遍單元測試，如果單元測試都通過，基本上可以保證我們的重構(gòu)沒有破壞原來代碼邏輯的正確性。不過前提是之前的寫的單元測試質(zhì)量很好，覆蓋率很高。當(dāng)然這僅限于小范圍的重構(gòu)，比如重構(gòu)一個(gè)類或者函數(shù)的實(shí)現(xiàn)，但對(duì)于大刀闊斧的重構(gòu)（比如單體重構(gòu)成微服務(wù)，面向庫表模式重構(gòu)成DDD），就不適用，那個(gè)時(shí)候要重寫單元測試了。

（3）通過單元測試快速熟悉代碼

單元測試不僅起到了測試的作用，還是一種很好的“文檔”，通過單元測試，我們不需要深入的閱讀代碼，便能知道這段代碼做什么工作，有哪些特殊情況需要考慮，包含哪些業(yè)務(wù)。

五、小結(jié)

• 何時(shí)寫
  單元測試與具體實(shí)現(xiàn)代碼同時(shí)進(jìn)行。

• 寫多細(xì)
  哪些代碼需要有單元測試覆蓋：
  1、邏輯復(fù)雜的
  2、容易出錯(cuò)的
  3、不易理解的，即使是自己過段時(shí)間也會(huì)遺忘的，看不懂自己的代碼，單元測試代碼有助于理解代碼的功能和需求
  4、公共代碼。比如自定義的所有http請(qǐng)求都會(huì)經(jīng)過的攔截器；工具類等。
  5、 核心業(yè)務(wù)代碼。一個(gè)產(chǎn)品里最核心最有業(yè)務(wù)價(jià)值的代碼應(yīng)該要有較高的單元測試覆蓋率。

總結(jié)

以上是生活随笔為你收集整理的单元测试系列一-为什么要写单元测试，何时写，写多细的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。