一、不寫單元測試的理由
工作幾年捆等，遇到過不少抗拒寫單元測試的人滞造，總結(jié)一下大致有以下這么幾個理由：
首先，寫單元測試所支出的時間可能比實現(xiàn)功能本身所花費的時間還多栋烤。言外之意谒养，在實現(xiàn)完所有功能之前不值得寫單元測試。如果現(xiàn)階段功能開發(fā)大致完畢明郭，可能也不會去補上虧欠的單元測試买窟，理由大致有這么幾點：
- 需求總是無窮盡的，還有下階段功能需求要實現(xiàn)薯定，沒空補單元測試始绍。
- 要補的單元測試太多，無從下手话侄，主觀上抗拒亏推。
- 單元測試編寫難度大学赛。一方面原因可能是功能函數(shù)實現(xiàn)上不夠合理，另一方面是沒有(或者不知道)好用的單元測試框架和mock框架吞杭。
- 單元測試不算入工作量內(nèi)盏浇。
其次，功能需求還不穩(wěn)定芽狗，寫單元測試的性價比不高绢掰。換句話說，萬一明天需求一變童擎，那不光功能代碼廢了滴劲，單元測試也廢了。如果不寫單元測試柔昼，那這部分工夫就不會白費哑芹。
二炎辨、寫單元測試的投入產(chǎn)出比
以投入產(chǎn)出比作為這個問題的判斷依據(jù)捕透，我覺得是所有理性人都會做出的選擇。而既然引入了投入產(chǎn)出比這個經(jīng)濟(jì)學(xué)上的概念碴萧，那么應(yīng)該也能接受另一個經(jīng)濟(jì)學(xué)上的普世規(guī)律——邊際收益遞減乙嘀。以及資源(主要指時間和精力)具有稀缺性這一規(guī)律。
下面的分析都將是建立在以上這些共識的基礎(chǔ)之上破喻，如果你并不認(rèn)同這些規(guī)律同樣可以用來分析軟件開發(fā)過程中值不值得寫單元測試這個問題虎谢，那么閱讀以下內(nèi)容僅僅是在浪費你寶貴的時間。如果你繼續(xù)往下閱讀曹质，那么婴噩，我將假設(shè)你已經(jīng)和我達(dá)成了這些共識。
雖然要為這個問題做精確的投入產(chǎn)出比定量分析比較困難羽德，但并不妨礙我們通過定性分析來得出自己心中的答案几莽。
成本(投入)
- 編寫單元測試用例所額外付出的時間，短期內(nèi)會拖慢項目進(jìn)度宅静。
收益(產(chǎn)出)
提升代碼質(zhì)量章蚣。監(jiān)督開發(fā)人員寫出更加易于測試和可維護(hù)的代碼。
提升開發(fā)團(tuán)隊內(nèi)部的協(xié)作效率姨夹。其他開發(fā)人員可以通過閱讀單元測試用例來理解代碼原作者的意圖纤垂。
保證功能實現(xiàn)的長期穩(wěn)定。代碼一旦發(fā)生與原功能意圖不相符的變化磷账，通過跑單元測試可以體現(xiàn)出來峭沦，即可以防止功能被無意識地破壞。
提高自動化測試占比逃糟，降低其他測試方式上的投入熙侍。
從上面我所羅列的成本/收益數(shù)量上說，收益的數(shù)量遠(yuǎn)大于成本。但是蛉抓，分析投入產(chǎn)出比并不是掰手指數(shù)數(shù)量就能得出答案的庆尘，特此說明。
首先巷送，短期項目不寫單元測試是劃算的選擇驶忌。至于到底多長時間算作短期，并無定論笑跛。我選擇將一個月作為劃分的界限付魔，一月以內(nèi)為短期，多于一月是中期或者長期飞蹂，至于中長期的界限在哪兒几苍，這個無關(guān)緊要，暫且不論陈哑。
短期項目的典型代表就是演示用demo項目妻坝。這類項目的共性是時間緊迫，項目生命周期短惊窖，無需后續(xù)的維護(hù)，使用一次性(或者接近一次性)圣拄。如果說中長期項目的使用周期(區(qū)別于開發(fā)周期)是時間段的話凭疮，那么短期項目的使用周期就是一個時間點或者幾個時間點。這種情況下將有限的資源投入到單元測試中逝淹，所獲得的收益并不明顯。如果繼續(xù)追加投入欣簇，由于收益增幅平緩，投入產(chǎn)出比極低，甚至為負(fù)。索性零投入零產(chǎn)出，雖然略顯保守呻粹，但也不失為一個好的選擇楣富。
其次塘安，中長期項目不寫單元測試絕對不是劃算的選擇。請注意集漾，這里我并沒有說中長期項目寫單元測試是劃算的選擇這樣的話切黔。因為寫單元測試這個說法太寬泛。很明顯具篇，單元測試覆蓋率1%與99%是有巨大區(qū)別的纬霞，而這兩者都屬于寫單元測試這個范疇。
對于中長期項目驱显，將資源投入到單元測試上所獲得的收益曲線會是這樣(不太會畫圖诗芜，暫且用文字描述)：
橫坐標(biāo)為投入瞳抓，縱坐標(biāo)為產(chǎn)出。
開始階段伏恐，隨著投入的增加孩哑，收益(產(chǎn)出)增幅明顯，曲線比較陡峭翠桦。
當(dāng)投入到達(dá)某一臨界值臭笆，單位投入所獲得的收益最大。
當(dāng)投入繼續(xù)追加并超過臨界值秤掌，收益的增幅明顯放緩愁铺，曲線開始變得平緩，單位投入所獲得的收益越來越少闻鉴，即邊際收益遞減茵乱。
如果你也認(rèn)可以上的投入產(chǎn)出比曲線，那么不難推出以下幾個結(jié)論：
不寫單元測試一定不是最佳選擇孟岛。
不寫單元測試可以理解為是零投入/零成本瓶竭，那么必然的也會是零收益。寫單元測試并且單元測試的覆蓋率接近100%也一定不是最佳選擇渠羞。由于邊際收益遞減斤贰，投入一旦越過臨界值，那么繼續(xù)追加投入所帶來的收益將越來越少次询。
臨界值才是理論上的最佳選擇荧恍。
上面提到的臨界值是屬于寫單元測試的范疇，并且單元測試覆蓋率在0%~100%之間的某個點屯吊。所以說送巡，軟件開發(fā)過程中值不值得寫單元測試這個問題的答案應(yīng)該無需再多言了。
文章一開始提到的那些不寫單元測試的理由盒卸，往往是抱著一個非黑即白的觀點骗爆，認(rèn)為不寫單元測試的反面就是寫單元測試且覆蓋率近100%。因而會過分夸大寫單元測試的成本(單元覆蓋率100%的代價當(dāng)然大)蔽介，選擇短期利益摘投。
三、個人的做法
下面以個人的小開源項目gbb為例虹蓄，啰嗦幾句我自己寫單元測試的習(xí)慣犀呼。
開源項目一定要寫單元測試！開源項目一定要寫單元測試武花！開源項目一定要寫單元測試圆凰！按照規(guī)定，重要的事情得說三遍体箕。除了上文提到的單元測試的好處外专钉，單元測試也是開源項目負(fù)責(zé)任的一種體現(xiàn)挑童。我花了時間去構(gòu)思各種情況下的測試用例，我能為開源項目質(zhì)量負(fù)責(zé)跃须。
不是非得寫完一個函數(shù)就必須立馬寫單元測試或者TDD站叼。關(guān)于寫單元測試的時機，我一般選擇在完成一個基本功能后寫單元測試菇民，優(yōu)先覆蓋功能的主體邏輯尽楔，一些邊界條件邏輯不會體現(xiàn)在這個階段的單元測試當(dāng)中。我覺得這個階段也是投入產(chǎn)出比最大的階段第练。
等功能相對穩(wěn)定后阔馋，再把一些邊界條件邏輯納入到單元測試當(dāng)中。這是單元測試覆蓋率提升較大的階段娇掏。
最后一個階段是刷數(shù)據(jù)階段(gbb項目單元測試覆蓋率曲線)呕寝。所謂的
刷數(shù)據(jù)階段的主要目標(biāo)就是為了讓覆蓋率盡可能提高。刷數(shù)據(jù)并不是在某個功能成熟穩(wěn)定后開始婴梧，我是選擇在開源項目進(jìn)入成熟階段后開始刷單元測試覆蓋率下梢，為的就是使其更加好看。對于非開源項目塞蹭，建議選擇跳過這個摳細(xì)節(jié)的階段孽江。
四、參考
在寫這篇博客時番电，我并沒有查閱相關(guān)的這類文章岗屏。為的就是防止他人的觀點在不知不覺中摻入其中，影響了我的原始觀點钧舌。
