單元測試進行曲 單元測試
又是老生常談-'單元測試'，說實話自己在單元測試上是'語言上的巨人，行動上的矮子'，屬于那種說的比做的多的人^_^。不過也不能說什么也沒做。記得去年年末的時候自己還設計并實現過一個簡單的'C語言單元測試包'呢^_^，至今這個包仍然還在使用呢。不過大多數的單元測試都不像想象中那樣簡單，我們在介紹單元測試的時候，大多拿Add、Sub等作例子，這樣當然有好處，簡單易懂。其實學習單元測試初期關鍵是學習單元測試的思想，所以這些Add、Sub也能滿足需求。不過在真正的項目中，單元測試大多做起來較為困難，我是在Unix上做C開發的，Java的咱暫先不提，也沒什么資格提，雖然曾經花過一段時間專心研究過，還寫過些Java學習心得，但是畢竟沒做過實際的項目，說起來心里也發虛。
曾經很長一段時間，自己在編碼階段基本上都是缺少單元測試的，一是項目中Legacy代碼較多，耦合太緊，想把那部分代碼拿出來比'登天還難'(有點夸張)，反正基本上是'一扯一大幫'，俗稱'一個都不能少';而是部門在這方面積淀較少，在計劃的時候對這方面考慮不夠，時間上也不充裕，經常是在集成測試或者系統測試的時候順便帶上單元測試了，這樣的后果就是'浪費'。本來在單元測試階段發現一個Bug需要10 minutes，拖到集成測試或者系統測試后，這個時間就可能是1 hour或者 1 day 或者更多時間，這里可不是'聳人聽聞'，的確有真實的事例，有過這樣的經歷的人都體會到其中的痛苦。
痛定思痛，自己終于覺醒了。恰好，一個新的短期項目剛剛處于開發階段，正好是發揮單元測試的大好時機。殺開一條血路，做就是了。但是不能盲目去做。單元測試是需要設計的，而且感覺單元測試設計因系統架構模式而異，有難有易;而且單元測試設計時需要考慮項目進度、測粒度和測試密度。測試粒度，也就是說你選擇多大的功能單元來作為單元測試的基本單元，是函數一級的還是模塊一級的;測試密度，則是你的單元測試用例的語句覆蓋度有多少了。完美的單元測試是應該覆蓋程序運行的每條分支的，但是要編寫出這么多的單元測試用例，其工作量我想比開發這個系統的工作量只多不少，這樣一來即使你能編寫出這么多用例的代碼，你的Leader也會對你吼的。選擇關鍵路徑覆蓋是我的選擇測試密度的'標準'。我們的系統的架構是基于'隊列/管道架構模式'的，這也決定了我們的單元測試較容易，根據這個特點我選擇我的單元測試的力度是模塊一級的�；静呗跃褪歉鶕K內的關鍵路徑設計模塊級別的單元測試用例--對我們這個系統來說具體就是造各種各樣的消息，放到輸入隊列中即可。
我的單元測試已經進行了兩天多了，效果很是明顯，有些bug的發現都出乎我的意料。每當測試完一個功能模塊，我會感覺對這個模塊更有信心了，還有一種莫名的成就感^_^。
好的單元測試最好是能自動化，這樣一旦修改了代碼，可以對以前測試過的代碼進行回歸單元測試，保證此次修改不影響到以前已經測試過的代碼的正確性。不過自動化又談何容易?Java有很好的工具支持，可謂眾星捧月;C則是孤家寡人，少有有利的工具支持。這樣的話，我們就需要自己寫自動化的邏輯，當然這些邏輯因系統而異，至今我也很難想出好的通用的辦法，比如像Mock Test這樣的測試，在C中就很難實現，我們常常以真實的情景代之，而不是使用Mock，這樣就可能讓不同的用例對執行順序有一個依賴，執行順序不一致，測試的結果可能不相同。
以上的一些經驗都有一定的語言局限性，對于使用C開發的系統可能有些借鑒的意義，但是對于Java開發的系統上面的很多說法也許還是誤導的，大家一定要'睜大眼睛'，看清楚了^_^。單元測試仍在進行中...^_^
文章來源于領測軟件測試網 http://www.kjueaiud.com/
