我對單元測試的理解

我將寫單元測試代碼看做開發的一個工具，就像ide起同樣的做用，幫助咱們開發。

寫單元測試最好在第一個接口函數完成時就開始寫，不然代碼多了，就不原意寫了。

有框架能夠用框架，沒框架自已寫個簡單的程序驗證一下自已的假設便可。

我通常c++用gtest和gmock，c#用nunit，java用junit。用法都很簡單。mock會麻煩一些，找個教程多看一看就差很少了。主要是對單元測試的理解。

其實不少開源項目都是寫一個簡單的小程序，printf出相關數據看是否與自已指望的一致。

真正寫起來，單元測試代碼量不多，不然說明你接口設計的有問題。這就引出單元測試代碼的做用，幫助你寫出好的接口。

好的接口要功能明確，職責單一，若是一個接口乾多件事，你的單元測試就無法寫，由於太多了。若是一個接口的單元測試函數超過四五個，就建議你好好考慮是否接口設計的有問題，對這個接口甚至整個功能作什麼是否真的想清楚了。包職責是否單一，是否合理的分層。若是未合理分層，也會致使單元測試代碼膨脹。

有些時候你會遇到單元測試很差寫，過分依賴mock才能寫測試代碼，這是由於代碼的耦合度高的原故，應該讓代碼儘可能獨立，低耦合。減小對其它模塊或者環境的依賴。例如你在一個接口中依賴了系統時間，這個單元測試就比較難寫，倒不是難寫代碼，而是你運行時總不能等待系統時間吧。這時就有了對系統環境的依賴，最好的辦法是將時間做爲參數傳進去。固然用mock也能夠解決難測的問題，但這不是正確的解決辦法。

寫單元測試代碼還有助於你寫出符合開放封閉元則的代碼。很簡單，你通常不會將一個原本應爲private的函數寫成public的，由於須要測試啊。

若是你關注了接口，真正考慮好了接口，功能的定位，符合了開放封閉原則，也不大須要重構，或者說在開發階段就已完成大部分重構了。

由於代碼進行了很好的分層，之後既使功能有改動，通常狀況下也不會影響全部層。

若是是寫c或c++代碼，你也不會多引入頭文件，由於單元測試代碼，不少時候要自已寫makefile，你多引入了頭文件，makefile會變複雜。

你也不會寫超長的函數，由於超長的函數通常很難測試。

你也不會過分使用繼承與虛函數，而會考慮組合，由於繼承與虛函數也很難測。

其實不少時候單元測試代碼比想像象中的少，寫起來也比想象中簡單，前提是你想明天接口要作什麼，接口設計好。

可是單元測試不容易上手，我以爲主要是難以想明白：把寫單元測試代碼當作測試而不是開發輔助手段；什麼tdd一堆的概念弄得人暈頭轉向；總以爲寫單元測試代碼很高大上，須要框架支持才能作；總以爲單元測試代碼會不少，會是實際代碼的好幾倍；老是在代碼完成後才寫單元測試代碼，這時發現單元測試代碼根本無法寫，接口設計不合理，耦合度高等；必定要團隊總體提倡纔好寫，不然生產率低。這些想法都不必。

千萬不要等到全部代碼都完成再寫單元測試代碼，由於這時候寫單元測試代碼意義已經不大，並且不少狀況下，這時候已經無法寫單元測試了，已完成代碼極可能存在接口設計不合理，耦合度高等問題，且單元測代碼量會很大，望而生畏。同理，也不要爲別人寫單元測試代碼，也不要別人替你寫單元測試代碼。

其實寫單元測試代碼對總體時間來講不是延長了，而是縮短了，由於通常一個功能要經過，須要詢試幾回，包括編譯（通常要所有編譯），發佈，手動驗證，有些時候還須要配置環境，而單元測試代這些均可以自動化。並且單元測試代碼已經提早協助作了重構。代碼質量獲得了提升。被測試人員測出的bug也會有所減小。

不少人開始考慮寫單元測試代碼，是以爲單元測試代碼對重構有幫助，主要是指後期重構。開始也是這樣理解。真正開始寫了後發現，對代碼的前期（全部代碼完成前）幫助最大。有時我甚至會前期寫單元測試代碼，後期就直接忽略了（由於以爲有時候小的改動對邏輯沒影響，單元測試代碼也就懶得同步了），固然這不是好習慣。

還有，不少人說單元測試是白盒測試，講求代碼覆蓋率。這也是不少人以爲單元測試代碼難寫寫的緣由之一。其實單元測試不該該講代碼覆蓋率，而應該是功能或邏輯覆蓋。某一個接口函數，是幹什麼的，有幾種可能性，都考慮到了，寫了相關的測試函數，也就能夠了，不用講代碼覆蓋率，不過這些覆蓋了，代碼也就覆蓋了，不然可能有廢代碼。還有，從接口函數角度看，我以爲是黑盒的。並且容許裏面的實現變更，只要測試函數都能經過便可。

寫單元測試僅僅是個開發的輔助工具，不是非它不可，寫不寫都不用糾結。個人建議是早點動手實踐，在實踐中反思。沒有真正想通，或以爲沒用，就先放一放。

寫單元測試也有不少限制，修改已有代碼很難寫單元測試代碼。數據庫操做，界面我不知道怎麼寫單元測試。

編輯於 2017-08-20

著做權歸做者全部