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

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

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

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

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

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

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

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

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

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

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

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

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

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

迷思6：單元測試就是浪費時間

你要弄明白什么才是浪費時間？

• 一而再再而三地修改同樣的漏洞
• 在整個開發(fā)過程中編寫或者重寫驗證代碼
• 修補(bǔ)了一個漏洞，不料在其他地方莫名其妙地出現(xiàn)另一個漏洞
• 在編寫代碼期間被意外打斷，完全不知道該怎么辦

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

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

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

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

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

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

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

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

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

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

事實是：單元測試雖然不能解決你調(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ā)人員為了追 求更好的編碼方式而作更改的原因，那么為什么不這么做呢。

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

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

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

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

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

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

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

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

更多新體驗，歡迎試用Parasoft與PRQA 旗下的各種測試工具。另外還有5折限時搶購和免費領(lǐng)iPhone 6、iPad air等好禮!