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

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

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

迷思2 :單元測試減慢了開發過程

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

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

迷思3：單元測試讓開發人員遠離代碼

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

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

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

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

事實是：可以把單元測試的結構和劃分重復應用到問答給你編寫中，這樣你將不僅僅可以編寫出更高質量的文檔，而且編寫文檔會更加容易，更加舒服了。有一些開發人員把產品的藍圖做為創建單元測試的啟發點，同樣可以把他們看作編寫文檔的框架。

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

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

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

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

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

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

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

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

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

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

迷思8：只有在許多人進行開發的時候才需要進行單元測試

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

事實是：單元測試對一個人組成的團隊的幫助同隊50個人組成的團隊一樣多。而且從資產保護的角度看，讓單個人掌握所有的東西甚至會冒更大的風險。

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

絕對不是這樣的。單元測試可以讓程序調試更加簡單，因為這樣你就可以把精力集中在有問題的代碼上，修補問題，接著再重新合并修改后代碼。在增加功 能的時候，它還可以防止引入漏洞，尤其在使用面向對象方法編程的時候，它還可以阻止問題令人非常沮喪地反復出現。單元測試不能確保100%的排除漏洞，不 過它卻是減少漏洞的好方法。

事實是：單元測試雖然不能解決你調試過程中遇到的所有問題，但是在你發現漏洞的時候，單元測試中相互隔離的代碼可以讓漏洞的修補更加容易。根據開發人員中單元測試的鐵桿粉絲所說，進行單元測試的最大好處就是讓程序的調試非常容易了，簡單了。

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

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

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

迷思11：使用單元測試進行程序調試覆蓋不全面

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

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

迷思12：單元測試增加了開發費用

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

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

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

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