軟件評測師：為什么要進行煩人的單元測試？

　　它僅僅是證明這些代碼做了什么

　　這是那些沒有首先為每個單元編寫一個詳細(xì)的規(guī)格說明而直接跳到編碼階段的開發(fā)人員提出的一條普遍的抱怨， 當(dāng)編碼完成以后并且面臨代碼測試任務(wù)的時候，他們就閱讀這些代碼并找出它實際上做了什么，把他們的測試工作基于已經(jīng)寫好的代碼的基礎(chǔ)上。當(dāng)然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這些。

　　如果他們首先寫好一個詳細(xì)的規(guī)格說明，測試能夠以規(guī)格說明為基礎(chǔ)。代碼就能夠針對它的規(guī)格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規(guī)格說明中的錯誤。好的規(guī)格說明可以使測試的質(zhì)量更高，所以最后的結(jié)論是高質(zhì)量的測試需要高質(zhì)量的規(guī)格說明。

　　在實踐中會出現(xiàn)這樣的情況： 一個開發(fā)人員要面對測試一個單元時只給出單元的代碼而沒有規(guī)格說明這樣吃力不討好的任務(wù)。你怎樣做才會有更多的收獲，而不僅僅是發(fā)現(xiàn)編譯器的Bug?第一步是理解這個單元原本要做什么， --- 不是它實際上做了什么。 比較有效的方法是倒推出一個概要的規(guī)格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調(diào)用它和被它調(diào)用的相關(guān)代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規(guī)格說明的走讀(Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設(shè)計單元測試了。

　　我是個很棒的程序員， 我是不是可以不進行單元測試?

　　在每個開發(fā)組織中都至少有一個這樣的開發(fā)人員，他非常擅長于編程，他們開發(fā)的軟件總是在第一時間就可以正常運行，因此不需要進行測試。你是否經(jīng)常聽到這樣的借口?

　　在真實世界里，每個人都會犯錯誤。即使某個開發(fā)人員可以抱著這種態(tài)度在很少的一些簡單的程序中應(yīng)付過去。 但真正的軟件系統(tǒng)是非常復(fù)雜的。真正的軟件系統(tǒng)不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。

　　編碼不是一個可以一次性通過的過程。在真實世界中，軟件產(chǎn)品必須進行維護以對操作需求的改變作出反應(yīng)， 并且要對最初的開發(fā)工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎? 這些制造出這些未經(jīng)測試的原始代碼的資深專家們還會繼續(xù)在其他地方制造這樣的代碼。在開發(fā)人員做出修改后進行可重復(fù)的單元測試可以避免產(chǎn)生那些令人不快的負(fù)作用。

　　不管怎樣， 集成測試將會抓住所有的Bug

　　我們已經(jīng)在前面的討論中從一個側(cè)面對這個問題進行了部分的闡述。這個論點不成立的原因在于規(guī)模越大的代碼集成意味著復(fù)雜性就越高。如果軟件的單元沒有事先進行測試，開發(fā)人員很可能會花費大量的時間僅僅是為了使軟件能夠運行，而任何實際的測試方案都無法執(zhí)行。

　　一旦軟件可以運行了，開發(fā)人員又要面對這樣的問題： 在考慮軟件全局復(fù)雜性的前提下對每個單元進行全面的測試。 這是一件非常困難的事情，甚至在創(chuàng)造一種單元調(diào)用的測試條件的時候，要全面的考慮單元的被調(diào)用時的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復(fù)雜程度遠(yuǎn)遠(yuǎn)的超過獨立進行的單元測試過程。

　　最后的結(jié)果是測試將無法達(dá)到它所應(yīng)該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。

　　讓我們類比一下，假設(shè)我們要清洗一臺已經(jīng)完全裝配好的食物加工機器!無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機器的死角位置，只有任其腐爛并等待以后再想辦法。但我們換個角度想想，如果這臺機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費力的進行清洗。