在真實世界里，每個人都會犯錯誤。即使某個開發人員可以抱著這種態度在很少的一些簡單的程序中應付過去。 但真正的軟件系統是非常復雜的。真正的軟件系統不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。
編碼不是一個可以一次性通過的過程。在真實世界中，軟件產品必須進行維護以對操作需求的改變作出反應， 并且要對最初的開發工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎? 這些制造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方制造這樣的代碼。在開發人員做出修改后進行可重復的單元測試可以避免產生那些令人不快的負作用。
不管怎樣， 集成測試將會抓住所有的Bug我們已經在前面的討論中從一個側面對這個問題進行了部分的闡述。這個論點不成立的原因在于規模越大的代碼集成意味著復雜性就越高。如果軟件的單元沒有事先進行測試，開發人員很可能會花費大量的時間僅僅是為了使軟件能夠運行，而任何實際的測試方案都無法執行。
一旦軟件可以運行了，開發人員又要面對這樣的問題： 在考慮軟件全局復雜性的前提下對每個單元進行全面的測試。 這是一件非常困難的事情，甚至在創造一種單元調用的測試條件的時候，要全面的考慮單元的被調用時的各種入口參數。在軟件集成階段，對單元功能全面測試的復雜程度遠遠的超過獨立進行的單元測試過程。
最后的結果是測試將無法達到它所應該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。
讓我們類比一下，假設我們要清洗一臺已經完全裝配好的食物加工機器!無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機器的死角位置，只有任其腐爛并等待以后再想辦法。但我們換個角度想想，如果這臺機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費力的進行清洗。
它的成本效率不高一個特定的開發組織或軟件應用系統的測試水平取決于對那些未發現的Bug的潛在后果的重視程度。這種后果的嚴重程度可以從一個Bug引起的小小的不便到發生多次的死機的情況。這種后果可能常常會被軟件的開發人員所忽視(但是用戶可不會這樣)，這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發組織的信譽，并且會導致對未來的市場產生負面的影響。相反地，一個可靠的軟件系統的良好的聲譽將有助于一個開發組織獲取未來的市場。
很多研究成果表明，無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產品進行測試將使效率和質量得到最好的保證。Bug發現的越晚，修改它所需的費用就越高，因此從經濟角度來看， 應該盡可能早的查找和修改Bug.在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。
相比后階段的測試，單元測試的創建更簡單，維護更容易，并且可以更方便的進行重復。從全程的費用來考慮， 相比起那些復雜且曠日持久的集成測試，或是不穩定的軟件系統來說，單元測試所需的費用是很低的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/