事實卻是相反的。進行單元測試的最大優點之一就是能夠對程式碼進行大型修改，然後立即對所做更改進行正確性測試。進行程式碼修改，後來蔡意識到軟體的其他部分受到了影響，接下來試圖隔離出引起問題的程式碼，這不單單使得程式碼的更改更加困難，也讓開發人員恐懼更改程式碼。
事實是：單元測試使得程式碼更改更加容易，而且也讓開發人員毫無顧慮地修改程式碼。一遍，兩遍等等。能對程式碼修改是人們選擇進行單元測試的最大的理由之一。
迷思2 :單元測試減慢了開發過程
進行單元測試一開始會讓開發過程慢一點，然而事實是這麼做反而節省了時間：它在開發過程繼續進行之前就防止了錯誤，並識別出錯誤出現的地方。而且 單元測試也使得開發人員對自己已經完成的工作更加有信心，這樣就會掃清開發過程中出現的障礙。縱觀整個開發過程，進行單元測試最終會使得總體花費時間會更短。
事實是：像任何一種新工具一樣，習慣進行單元測試也需要一點時間，不過，總的來說，進行單元測試可以節省時間，同時浪費的時間也會縮短。實際上， 進行迴歸測試可以持續不斷地推進開發過程，並且不會有任何擔心。假若在日常構建時進行單元測試，那麼這樣的測試是不會佔用開發時間的。
迷思3：單元測試讓開發人員遠離程式碼
這是很顯然的誤解。正是開發人員才能幫助設計測試程式。這就意味著開發人員需要更加深入的瞭解程式碼功能，而且要對整個程式中的更小單元的功能負更多地責任。在我們檢視整個程式的時候，有時候很容易忽視函式和過程，然而，有了單元測試，我們就不會對函式和過程視而不見了。
事實是：與其他方法相比，單元測試要求開發人員不僅僅要看得懂程式碼和程式碼的意圖，而且要明瞭各種測試條件，輸入和輸出，這樣就可以測試出在其他測試條件下可能未測出的功能。正是進行了單元測試，我們才會更加關注函式和過程。
迷思4：單元測試使得文件編寫更加困難
單元測試不但不會使文件的編寫更加困難，而且會讓文件的編寫更加細緻，這不是壞事。沒有人真正喜歡編寫文件，不過單元測試使得編寫文件不再那麼費勁。開發人員發現在進行單元測試的時候編寫文件會更加容易一些，此時編寫文件是對單元測試中各個過程和函式的反思。
事實是：可以把單元測試的結構和劃分重複應用到問答給你編寫中，這樣你將不僅僅可以編寫出更高質量的文件，而且編寫文件會更加容易，更加舒服了。有一些開發人員把產品的藍圖做為建立單元測試的啟發點，同樣可以把他們看作編寫文件的框架。
迷思5：一旦專案結束，那麼投入到單元測試上的工作就廢掉了
完全不是這樣的。如果你曾經重用過程式碼，那麼你將會意識到你所做的一切都是資產。
事實是：在你在一個專案中採用了以前為另一個專案寫的程式碼，或者對這段程式碼進行編輯的時候，你可以採用相同的單元測試，也可以對這些單元測試進行編輯。在同一個專案中使用相似的測試程式碼段也是沒有問題的。
迷思6：單元測試就是浪費時間
你要弄明白什麼才是浪費時間？
- 一而再再而三地修改同樣的漏洞
- 在整個開發過程中編寫或者重寫驗證程式碼
- 修補了一個漏洞，不料在其他地方莫名其妙地出現另一個漏洞
- 在編寫程式碼期間被意外打斷，完全不知道該怎麼辦
拒絕進行單元測試是可以理解的，不過許多開發人員只有在使用單元測試完成一個專案以後，他們才會稱讚單元測試多麼的好。
事實是：你只需編寫單元測試一次，但可多次執行。這與你對其他程式碼的修改沒有任何關係。一開始進行的投入會得到長期的回報。
迷思7：這段程式碼已經非常簡單了，為什麼還要編寫測試程式碼呢？
程式碼似乎很簡單，然而直到出現問題的時候，此時事情就不再那麼簡單了。編寫單元測試，甚至為簡單程式碼編寫單元測試，毫無疑問可以增加專案的穩定性和安全性。
事實是：簡單的程式碼需要簡單地測試，不要找什麼藉口。
迷思8：只有在許多人進行開發的時候才需要進行單元測試
在有許多開發人員進行開發的時候進行單元測試是一個很好的策略。然而由於只有一個開發人員而不進行單元測試則顯然是個錯誤。在許多開發人員開發時進行單元測試所能帶來的要好處也適宜於單個開發人員。
事實是：單元測試對一個人組成的團隊的幫助同隊50個人組成的團隊一樣多。而且從資產保護的角度看，讓單個人掌握所有的東西甚至會冒更大的風險。
迷思9：單元測試對程式除錯沒有任何幫助，或者說不能防止漏洞的出現
絕對不是這樣的。單元測試可以讓程式除錯更加簡單，因為這樣你就可以把精力集中在有問題的程式碼上，修補問題，接著再重新合併修改後程式碼。在增加功 能的時候，它還可以防止引入漏洞，尤其在使用物件導向方法程式設計的時候，它還可以阻止問題令人非常沮喪地反覆出現。單元測試不能確保100%的排除漏洞，不 過它卻是減少漏洞的好方法。
事實是：單元測試雖然不能解決你除錯過程中遇到的所有問題，但是在你發現漏洞的時候，單元測試中相互隔離的程式碼可以讓漏洞的修補更加容易。根據開發人員中單元測試的鐵桿粉絲所說，進行單元測試的最大好處就是讓程式的除錯非常容易了，簡單了。
迷思10：單元測試讓你採用的編碼方式有重大改變
編碼方式有重大改變？是的。編碼方式更好了？是的。哪些非常依賴全域性變數和單例模式進行程式設計的開發人員發現他們編寫的程式碼是緊耦合的。如果要對代 碼進行測試，那麼程式碼必須與資料是鬆耦合的，單例模式不適合這種場合。大多數情況下，使用全域性變數和單例模式的編碼不是最好的。如果測試是開發人員為了追 求更好的編碼方式而作更改的原因，那麼為什麼不這麼做呢。
事實是：使用單例模式最大的好處就是它解決了資源競爭問題，這種情況可能你極少遇到，比如進行日誌處理的時候。在其他情況下，單例模式程式設計只是一種老的程式設計習慣，益處非常少，而且會讓程式碼的測試極度困難。
迷思11：使用單元測試進行程式除錯覆蓋不全面
這僅僅是因為你不能對整個程式碼進行除錯，但這並不意味著除錯覆蓋不全面。使用單元測試進行程式除錯至少比其他型別的除錯效果好。事實上，單元測試 有一個非常突出的優點是：（如果不是大大地刪除，那麼就是）大大地減少彙報上面我所提到的漏洞的數量。在開發和除錯程式的時候，重現漏洞是一個令人非常沮 喪的事情。通過單元測試，你可以在增加、修改和刪除功能的時候減少引入新漏洞的頻率。除錯從來都是“全覆蓋的”，尤其是在程式執行的裝置或者系統差異非常 大的時候。
事實是：特別是在處理漏洞的時候，單元測試可以確保能找到從來都沒有彙報過的漏洞。而且在你進行程式除錯的時候，你不需要檢視全部程式碼，只需要修改出現漏洞的地方。
迷思12：單元測試增加了開發費用
能讓最優秀的開發人員落淚的事情是進行程式碼更改。專案經理，總經理（CEO），財務總監(CFO)和其他高階管理人員為了讓專案盈利，他們說出自 己的想法，然後算出後期的開發費用。在你為了盈利而付出實實在在的努力的情況下，管理人員卻要求立即進行大的修改或者決定拋棄這幾個月的工作，因為他們發 現這個功能沒有什麼市場。管理人員想讓一個產品真正的賺錢，那麼有時候這就意味著要進行大型修改或者要快速地進行大量的工作重心的轉移。
事實是：通過降低進行大型修改的難度，開發人員可以更靈活地滿足產品需求，這也會增加產品經濟上成功的機會。編寫可無缺陷執行且優美的程式碼是令人欽佩的，更好的情況是它能獲得經濟上的回報。
雖然對單元測試有許多誤解，但是對軟體的測試依然受到高度關注。這裡羅列了單元測試的12個迷思和對應的事實；希望你能以這些事實為鑑，以便以後能夠更有效地進行單元測試。
相關閱讀
評論(1)