Posted on 2011-09-15 06:37
RTY 閱讀(369)
評(píng)論(0) 編輯 收藏 引用 所屬分類(lèi):
轉(zhuǎn)載隨筆 、
質(zhì)量保障
剛接觸單元測(cè)試時(shí)，我實(shí)在是搞不懂這種測(cè)試到底有多大的意義，無(wú)非都是一些簡(jiǎn)單的ASSERT，但近年積累一些經(jīng)驗(yàn)教訓(xùn)之后我才發(fā)現(xiàn)，單元測(cè)試這玩意兒真的是一種保證程序質(zhì)量的強(qiáng)有力手段。
為什么這樣說(shuō)？舉個(gè)最典型的例子，無(wú)論是開(kāi)發(fā)新功能還是維護(hù)老程序，都不可避免的要反復(fù)修改某些代碼，那該怎么保證修改的代碼不會(huì)引入新的問(wèn)題？如果你說(shuō)你用人品擔(dān)保，那我服了。我們應(yīng)該需要一種可靠的手段來(lái)保證修改一個(gè)BUG不會(huì)引入兩個(gè)三個(gè)BUG，或者不會(huì)讓之前正確的功能出錯(cuò)，甚至是不會(huì)引入之前已經(jīng)修改過(guò)的其它BUG。測(cè)試無(wú)疑是一種很好的手段，在沒(méi)掌握其它更好的方法之前，很多人喜歡用人工測(cè)試，即編譯 – 運(yùn)行 – 輸入典型值 – 看程序運(yùn)行結(jié)果 – 如果出錯(cuò) – 修改后再編譯……從長(zhǎng)遠(yuǎn)來(lái)看，這種測(cè)試方法的缺點(diǎn)很明顯：1、耗時(shí)耗力，每次修改代碼后都需要人工重復(fù)測(cè)試所有的典型情況；2、容易出錯(cuò)、漏測(cè)，人腦太復(fù)雜，你很難記得幾個(gè)月前的那個(gè)BUG到底是什么情況，因此沒(méi)法測(cè)試，久而久之，N久前的那個(gè)BUG可能又神不知鬼不覺(jué)的重現(xiàn)了。相比之下，單元測(cè)試的優(yōu)點(diǎn)就凸顯出來(lái)了，把需要測(cè)試的典型情況編寫(xiě)為測(cè)試代碼，然后編譯運(yùn)行即可完成自動(dòng)化的測(cè)試，當(dāng)發(fā)現(xiàn)BUG后，把它添加到測(cè)試用例，不僅可以提高測(cè)試覆蓋率，還能保證以后不會(huì)再次引入同樣的BUG，有了足夠的單元測(cè)試（覆蓋率），你就可以理直氣壯的說(shuō)代碼沒(méi)問(wèn)題！當(dāng)然引入單元測(cè)試會(huì)在前期花費(fèi)不少的時(shí)間來(lái)編寫(xiě)測(cè)試代碼，但相應(yīng)的也會(huì)大大減少后期的維護(hù)工作，最主要的是能可靠的提高程序的質(zhì)量，所以是值得的，甚至是必要的。（如果你編譯過(guò)開(kāi)源的Google Chromium瀏覽器，你會(huì)發(fā)現(xiàn)測(cè)試代碼就占了不少，光是編譯測(cè)試代碼就得花很長(zhǎng)的時(shí)間）
除了上面說(shuō)的優(yōu)點(diǎn)外，單元測(cè)試還有一些其它的好處，比如幫你理清設(shè)計(jì)。一些人反對(duì)單元測(cè)試就是因?yàn)檎f(shuō)我們的應(yīng)用太復(fù)雜了，沒(méi)法做單元測(cè)試。其實(shí)不一定是應(yīng)用復(fù)雜，而有可能是設(shè)計(jì)得有問(wèn)題，導(dǎo)致了沒(méi)有可測(cè)試性。比如有些人喜歡在CXXXDialog里編寫(xiě)所有的功能實(shí)現(xiàn)，要測(cè)試這樣的代碼，必須得創(chuàng)建出Dialog，可能還需要點(diǎn)擊，這顯然沒(méi)法做單元測(cè)試，但如果把Dialog和業(yè)務(wù)邏輯分開(kāi)設(shè)計(jì)，那至少業(yè)務(wù)邏輯是可測(cè)試的（暫不討論UI的測(cè)試）。因此要做單元測(cè)試，就得設(shè)計(jì)好各個(gè)接口，保證某個(gè)接口只完成單一的功能，沒(méi)有過(guò)多的耦合依賴(lài)。
前面只是泛泛而談了一些單元測(cè)試的皮毛，鼓吹了一些優(yōu)點(diǎn)，有興趣的自己找更詳細(xì)的資料看吧。另推薦一個(gè)Google的開(kāi)源C++測(cè)試框架googletest。