摘要：這篇文章介紹了對單元測試的最常見的誤解，并給出誤解所對應(yīng)的事實(shí)的相關(guān)信息。

如今，單元測試雖然得到廣泛地應(yīng)用，但是仍然存在某些誤解。對于仍然看不到單元測試優(yōu)點(diǎn)的開發(fā)人員，以及無法使自己確信進(jìn)行單元測試是值得的項(xiàng)目經(jīng)理來說，單元測試依然受到質(zhì)疑。在下面的文章中，我們將介紹一些單元測試的迷思和與這些迷思對應(yīng)的最常見到的一些事實(shí)。

迷思1：單元測試使得更改變得更加困難

事實(shí)卻是相反的。進(jìn)行單元測試的***優(yōu)點(diǎn)之一就是能夠?qū)Υa進(jìn)行大型修改，然后立即對所做更改進(jìn)行正確性測試。進(jìn)行代碼修改，后來才意識到軟件的其他部分受到了影響，接下來試圖隔離出引起問題的代碼，這不單單使得代碼的更改更加困難，也讓開發(fā)人員恐懼更改代碼。

事實(shí)是：單元測試使得代碼更改更加容易，而且也讓開發(fā)人員毫無顧慮地修改代碼。一遍，兩遍等等。能對代碼修改是人們選擇進(jìn)行單元測試的***的理由之一。

迷思2 :單元測試減慢了開發(fā)過程

進(jìn)行單元測試一開始會讓開發(fā)過程慢一點(diǎn)，然而事實(shí)是這么做反而節(jié)省了時間：它在開發(fā)過程繼續(xù)進(jìn)行之前就防止了錯誤，并識別出錯誤出現(xiàn)的地方。而且單元測試也使得開發(fā)人員對自己已經(jīng)完成的工作更加有信心，這樣就會掃清開發(fā)過程中出現(xiàn)的障礙?？v觀整個開發(fā)過程，進(jìn)行單元測試最終會使得總體花費(fèi)時間會更短。

事實(shí)是：像任何一種新工具一樣，習(xí)慣進(jìn)行單元測試也需要一點(diǎn)時間，不過，總的來說，進(jìn)行單元測試可以節(jié)省時間，同時浪費(fèi)的時間也會縮短。實(shí)際上，進(jìn)行回歸測試可以持續(xù)不斷地推進(jìn)開發(fā)過程，并且不會有任何擔(dān)心。假若在日常構(gòu)建時進(jìn)行單元測試，那么這樣的測試是不會占用開發(fā)時間的。

迷思3：單元測試讓開發(fā)人員遠(yuǎn)離代碼

這是很顯然的誤解。正是開發(fā)人員才能幫助設(shè)計(jì)測試程序。這就意味著開發(fā)人員需要更加深入的了解代碼功能，而且要對整個程序中的更小單元的功能負(fù)更多地責(zé)任。在我們查看整個程序的時候，有時候很容易忽視函數(shù)和過程，然而，有了單元測試，我們就不會對函數(shù)和過程視而不見了。

事實(shí)是：與其他方法相比，單元測試要求開發(fā)人員不僅僅要看得懂代碼和代碼的意圖，而且要明了各種測試條件，輸入和輸出，這樣就可以測試出在其他測試條件下可能未測出的功能。正是進(jìn)行了單元測試，我們才會更加關(guān)注函數(shù)和過程。

迷思4：單元測試使得文檔編寫更加困難

單元測試不但不會使文檔的編寫更加困難，而且會讓文檔的編寫更加細(xì)致，這不是壞事。沒有人真正喜歡編寫文檔，不過單元測試使得編寫文檔不再那么費(fèi)勁。開發(fā)人員發(fā)現(xiàn)在進(jìn)行單元測試的時候編寫文檔會更加容易一些，此時編寫文檔是對單元測試中各個過程和函數(shù)的反思。

事實(shí)是：可以把單元測試的結(jié)構(gòu)和劃分重復(fù)應(yīng)用到問答給你編寫中，這樣你將不僅僅可以編寫出更高質(zhì)量的文檔，而且編寫文檔會更加容易，更加舒服了。有一些開發(fā)人員把產(chǎn)品的藍(lán)圖做為創(chuàng)建單元測試的啟發(fā)點(diǎn)，同樣可以把他們看作編寫文檔的框架。

迷思5：一旦項(xiàng)目結(jié)束，那么投入到單元測試上的工作就廢掉了

完全不是這樣的。如果你曾經(jīng)重用過代碼，那么你將會意識到你所做的一切都是資產(chǎn)。
事實(shí)是：在你在一個項(xiàng)目中采用了以前為另一個項(xiàng)目寫的代碼，或者對這段代碼進(jìn)行編輯的時候，你可以采用相同的單元測試，也可以對這些單元測試進(jìn)行編輯。在同一個項(xiàng)目中使用相似的測試代碼段也是沒有問題的。

迷思6：單元測試就是浪費(fèi)時間

你要弄明白什么才是浪費(fèi)時間？

• 一而再再而三地修改同樣的漏洞

• 在整個開發(fā)過程中編寫或者重寫驗(yàn)證代碼

• 修補(bǔ)了一個漏洞，不料在其他地方莫名其妙地出現(xiàn)另一個漏洞

• 在編寫代碼期間被意外打斷，完全不知道該怎么辦

拒絕進(jìn)行單元測試是可以理解的，不過許多開發(fā)人員只有在使用單元測試完成一個項(xiàng)目以后，他們才會稱贊單元測試多么的好。

事實(shí)是：你只需編寫單元測試一次，但可多次運(yùn)行。這與你對其他代碼的修改沒有任何關(guān)系。一開始進(jìn)行的投入會得到長期的回報(bào)。

迷思7：這段代碼已經(jīng)非常簡單了，為什么還要編寫測試代碼呢？

代碼似乎很簡單，然而直到出現(xiàn)問題的時候，此時事情就不再那么簡單了。編寫單元測試，甚至為簡單代碼編寫單元測試，毫無疑問可以增加項(xiàng)目的穩(wěn)定性和安全性。

事實(shí)是：簡單的代碼需要簡單地測試，不要找什么借口。

迷思8：只有在許多人進(jìn)行開發(fā)的時候才需要進(jìn)行單元測試

在有許多開發(fā)人員進(jìn)行開發(fā)的時候進(jìn)行單元測試是一個很好的策略。然而由于只有一個開發(fā)人員而不進(jìn)行單元測試則顯然是個錯誤。在許多開發(fā)人員開發(fā)時進(jìn)行單元測試所能帶來的要好處也適宜于單個開發(fā)人員。

事實(shí)是：單元測試對一個人組成的團(tuán)隊(duì)的幫助同隊(duì)50個人組成的團(tuán)隊(duì)一樣多。而且從資產(chǎn)保護(hù)的角度看，讓單個人掌握所有的東西甚至?xí)案蟮娘L(fēng)險(xiǎn)。

迷思9：單元測試對程序調(diào)試沒有任何幫助，或者說不能防止漏洞的出現(xiàn)

絕對不是這樣的。單元測試可以讓程序調(diào)試更加簡單，因?yàn)檫@樣你就可以把精力集中在有問題的代碼上，修補(bǔ)問題，接著再重新合并修改后代碼。在增加功能的時候，它還可以防止引入漏洞，尤其在使用面向?qū)ο蠓椒ň幊痰臅r候，它還可以阻止問題令人非常沮喪地反復(fù)出現(xiàn)。單元測試不能確保100%的排除漏洞，不過它卻是減少漏洞的好方法。

事實(shí)是：單元測試雖然不能解決你調(diào)試過程中遇到的所有問題，但是在你發(fā)現(xiàn)漏洞的時候，單元測試中相互隔離的代碼可以讓漏洞的修補(bǔ)更加容易。根據(jù)開發(fā)人員中單元測試的鐵桿粉絲所說，進(jìn)行單元測試的***好處就是讓程序的調(diào)試非常容易了，簡單了。

迷思10：單元測試讓你采用的編碼方式有重大改變

編碼方式有重大改變？是的。編碼方式更好了？是的。哪些非常依賴全局變量和單例模式進(jìn)行編程的開發(fā)人員發(fā)現(xiàn)他們編寫的代碼是緊耦合的。如果要對代碼進(jìn)行測試，那么代碼必須與數(shù)據(jù)是松耦合的，單例模式不適合這種場合。大多數(shù)情況下，使用全局變量和單例模式的編碼不是***的。如果測試是開發(fā)人員為了追求更好的編碼方式而作更改的原因，那么為什么不這么做呢。

事實(shí)是：使用單例模式***的好處就是它解決了資源競爭問題，這種情況可能你極少遇到，比如進(jìn)行日志處理的時候。在其他情況下，單例模式編程只是一種老的編程習(xí)慣，益處非常少，而且會讓代碼的測試極度困難。

迷思11：使用單元測試進(jìn)行程序調(diào)試覆蓋不全面

這僅僅是因?yàn)槟悴荒軐φ麄€代碼進(jìn)行調(diào)試，但這并不意味著調(diào)試覆蓋不全面。使用單元測試進(jìn)行程序調(diào)試至少比其他類型的調(diào)試效果好。事實(shí)上，單元測試有一個非常突出的優(yōu)點(diǎn)是：（如果不是大大地刪除，那么就是）大大地減少匯報(bào)上面我所提到的漏洞的數(shù)量。在開發(fā)和調(diào)試程序的時候，重現(xiàn)漏洞是一個令人非常沮喪的事情。通過單元測試，你可以在增加、修改和刪除功能的時候減少引入新漏洞的頻率。調(diào)試從來都是“全覆蓋的”，尤其是在程序運(yùn)行的設(shè)備或者系統(tǒng)差異非常大的時候。

事實(shí)是：特別是在處理漏洞的時候，單元測試可以確保能找到從來都沒有匯報(bào)過的漏洞。而且在你進(jìn)行程序調(diào)試的時候，你不需要查看全部代碼，只需要修改出現(xiàn)漏洞的地方。

迷思12：單元測試增加了開發(fā)費(fèi)用

能讓***秀的開發(fā)人員落淚的事情是進(jìn)行代碼更改。項(xiàng)目經(jīng)理，總經(jīng)理（CEO），財(cái)務(wù)總監(jiān)(CFO)和其他高級管理人員為了讓項(xiàng)目盈利，他們說出自己的想法，然后算出后期的開發(fā)費(fèi)用。在你為了盈利而付出實(shí)實(shí)在在的努力的情況下，管理人員卻要求立即進(jìn)行大的修改或者決定拋棄這幾個月的工作，因?yàn)樗麄儼l(fā)現(xiàn)這個功能沒有什么市場。管理人員想讓一個產(chǎn)品真正的賺錢，那么有時候這就意味著要進(jìn)行大型修改或者要快速地進(jìn)行大量的工作重心的轉(zhuǎn)移。

事實(shí)是：通過降低進(jìn)行大型修改的難度，開發(fā)人員可以更靈活地滿足產(chǎn)品需求，這也會增加產(chǎn)品經(jīng)濟(jì)上成功的機(jī)會。編寫可無缺陷運(yùn)行且優(yōu)美的代碼是令人欽佩的，更好的情況是它能獲得經(jīng)濟(jì)上的回報(bào)。

雖然對單元測試有許多誤解，但是對軟件的測試依然受到高度關(guān)注。這里羅列了單元測試的12個迷思和對應(yīng)的事實(shí)；希望你能以這些事實(shí)為鑒，以便以后能夠更有效地進(jìn)行單元測試。

英文原文：12 Unit Testing Myths and Practices