它浪費了太多的時間一旦編碼完成，開發人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。
在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug.在實踐中，這樣一種開發步驟常常會導致這樣的結果：軟件甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導致在軟件集成為一個系統時增加額外的工期， 而且當這個系統投入使用時也無法確保它能夠可靠運行。
在實踐工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩定可靠的部件的情況下，開發人員能夠進行更高效的系統集成工作。這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。
使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。
它僅僅是證明這些代碼做了什么這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨， 當編碼完成以后并且面臨代碼測試任務的時候，他們就閱讀這些代碼并找出它實際上做了什么，把他們的測試工作基于已經寫好的代碼的基礎上。當然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這些。
如果他們首先寫好一個詳細的規格說明，測試能夠以規格說明為基礎。代碼就能夠針對它的規格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規格說明中的錯誤。好的規格說明可以使測試的質量更高，所以最后的結論是高質量的測試需要高質量的規格說明。
在實踐中會出現這樣的情況： 一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。你怎樣做才會有更多的收獲，而不僅僅是發現編譯器的Bug?第一步是理解這個單元原本要做什么， —— 不是它實際上做了什么。 比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規格說明的走讀(Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設計單元測試了。
我是個很棒的程序員， 我是不是可以不進行單元測試?
在每個開發組織中都至少有一個這樣的開發人員，他非常擅長于編程，他們開發的軟件總是在第一時間就可以正常運行，因此不需要進行測試。你是否經常聽到這樣的借口?
文章來源于領測軟件測試網 http://www.kjueaiud.com/