認為單元測試影響開發(fā)進度，一是借口，拒絕對單元測試相關知識進行學習（單元測試，代碼重構，版本管理是開發(fā)人員的必備）；二是單元測試是“先苦后甜”，剛開始搭建環(huán)境，引入額外工作，看似“影響進度”，但長遠來看，由于程序質(zhì)量提升、代碼返工減少、后期維護工作量縮小、項目風險降低，從而在整體上贏了回來。
誤解一：影響開發(fā)進度
一旦編碼完成，開發(fā)人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到系統(tǒng)實際運行效果。這在外表上看來好像加快進度，而像單元測試這樣的活動被看作是影響進度原因之一，推遲了對整個系統(tǒng)進行集成測試的時間。
在實踐中，這種開發(fā)步驟常常會導致這樣的結果：軟件甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，它們會導致推遲軟件產(chǎn)品交付的時間，而且也無法確保它能夠可靠運行。
在實際工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，開發(fā)人員能夠進行更高效的系統(tǒng)集成工作。這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效利用。
誤解二：增加開發(fā)成本
如果不重視程序中那些未被發(fā)現(xiàn)的Bug可能帶來的后果。這種后果的嚴重程度可以從一個Bug引起的用戶使用不便到系統(tǒng)崩潰。這種后果可能常常會被軟件的開發(fā)人員所忽視，這種情況會長期損害軟件開發(fā)商的聲譽，并且會對未來的市場產(chǎn)生負面影響。相反地，一個可靠的軟件系統(tǒng)的良好的聲譽將有助于一個軟件開發(fā)商獲取未來的市場。
很多研究成果表明，無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進行測試將使效率和質(zhì)量得到最好的保證。Bug發(fā)現(xiàn)得越晚，修改它所需的費用就越高，因此從經(jīng)濟角度來看，應該盡可能早地查找和修改Bug。而單元測試就是一個在早期抓住Bug的機會。
相比后階段的測試，單元測試的創(chuàng)建更簡單，且維護更容易，同時可以更方便地進行重構。從全程的費用來考慮，相比起那些復雜且曠日持久的集成測試，或是不穩(wěn)定的軟件系統(tǒng)來說，單元測試所需的費用是很低的。
誤解三：我是個編程高手，無須進行單元測試
在每個開發(fā)團隊中都至少有一個這樣的開發(fā)人員，他非常擅長于編程，他開發(fā)的軟件總是在第一時間就可以正常運行，因此不需要進行測試。你是否經(jīng)常聽到這樣的借口？在現(xiàn)實世界里，每個人都會犯錯誤。即使某個開發(fā)人員可以抱著這種態(tài)度在很少的一些簡單程序中應付過去，但真正的軟件系統(tǒng)是非常復雜的。真正的軟件系統(tǒng)不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。編碼不是一個可以一次性通過的過程。在現(xiàn)實世界中，軟件產(chǎn)品必須進行維護以對功能需求的改變作出及時響應，并且要對最初的開發(fā)工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎？這些制造出未經(jīng)測試的代碼的資深工程師們還會繼續(xù)在其他地方制造這樣的代碼。在開發(fā)人員做出修改后進行可重復的單元測試，可以避免產(chǎn)生那些令人不快的負作用。
誤解四：測試人員會測出所有Bug
一旦軟件可以運行了，開發(fā)人員又要面對這樣的問題：在考慮軟件全局復雜性的前提下對每個單元進行全面的測試。這是一件非常困難的事情，甚至在創(chuàng)造一種單元調(diào)用的測試條件時，要全面考慮單元被調(diào)用時的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復雜程度遠遠超過獨立進行的單元測試過程。
最后的結果是測試將無法達到它所應該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。讓我們類比一下，假設我們要清理一臺電腦主機中的灰塵，如果沒有把主機中各個部件（顯卡、內(nèi)存等）拆開，無論你用什么工具，一些灰塵還會隱藏在主機的某些角落無法清理。但我們換個角度想想，如果把主機每個部件一一拆開，這些死角中的灰塵就容易被發(fā)現(xiàn)和接觸到了，并且每一部件的灰塵都可以毫不費力地進行清理。
單元測試之困境
測試在軟件開發(fā)過程中一直都是備受關注的，測試不僅僅局限于軟件開發(fā)中的一個階段，它已經(jīng)開始貫穿于整個軟件開發(fā)過程。大家普遍認識到，如果測試能在開發(fā)階段進行有效執(zhí)行，程序的Bug就會被及早發(fā)現(xiàn)，其質(zhì)量就能得到有效的保證，從而減少軟件開發(fā)總成本。但是，相對于測試這個詞的流行程度而言，大家對單元測試的認知普遍存在一些偏差，特別是一些程序員很容易陷入一些誤區(qū)，導致了測試并沒有在他們所在的開發(fā)項目中起到有效的作用。下面對一些比較具有代表性的誤區(qū)困境進行剖析，并對于測試背后所蘊含的一些設計思考進行闡述，希望能夠起到拋磚引玉的作用。
誤區(qū)、困境一：使用System.out.print跟蹤和運行程序就夠了
這個誤區(qū)可以說是程序員的一種通病，認為使用System.out.print就可以確保編寫代碼的正確性，無須編寫測試用例，他們覺得編寫用例是在“浪費時間”。使用System.out.print輸出結果，以肉眼觀察這種刀耕火種的方式進行測試，不僅效率低下，而且容易出錯。
誤區(qū)、困境二：存在太多無法測試的東西
在編碼的時候，確實存在一些看起來比較難測試的代碼，但是并非無法測試。并且在大多數(shù)情況下，還是由于被測試的代碼在設計時沒有考慮到可測試性的問題。編寫程序不僅與第三方一些框架耦合過緊，而且過于依賴其運行環(huán)境，從而表現(xiàn)出被測試的代碼本身很難測試。
誤區(qū)、困境三：測試代碼可以隨意寫
編寫測試代碼時抱著一種隨意的態(tài)度，沒有弄清測試的真正意圖。編寫測試代碼只是為了應付任務而已，先編寫程序?qū)崿F(xiàn)代碼，然后才去編寫一些單元測試。表現(xiàn)出來的結果是測試過于簡單，只走形式和花架，將大量Bug傳遞給系統(tǒng)測試人員。
誤區(qū)、困境四：不關心測試環(huán)境
手工搭建測試環(huán)境，測試數(shù)據(jù)，造成維護困難，占據(jù)了大量時間，嚴重影響效率。對測試產(chǎn)生的“垃圾”不清除，不處理。造成測試不能重復進行，導致脆弱的測試，需要維護好測試環(huán)境，做一個“低碳環(huán)保”的測試者。
誤區(qū)、困境五：測試環(huán)境依賴性大
測試環(huán)境依賴性大，沒有有效隔離測試目標及其依賴環(huán)境，一是使測試不聚焦；二是常因依賴環(huán)境的影響造成失敗；三是因依賴環(huán)境太厚重從而降低測試的效率（如依賴數(shù)據(jù)庫或依賴網(wǎng)絡資源，如郵件系統(tǒng)、Web服務）。