剛接觸單元測試時，我實在是搞不懂這種測試到底有多大的意義，無非都是一些簡單的ASSERT，但近年積累一些經驗教訓之后我才發現，單元測試這玩意兒真的是一種保證程序質量的強有力手段。

為什么這樣說？舉個最典型的例子，無論是開發新功能還是維護老程序，都不可避免的要反復修改某些代碼，那該怎么保證修改的代碼不會引入新的問題？如果你說你用人品擔保，那我服了。我們應該需要一種可靠的手段來保證修改一個BUG不會引入兩個三個BUG，或者不會讓之前正確的功能出錯，甚至是不會引入之前已經修改過的其它BUG。測試無疑是一種很好的手段，在沒掌握其它更好的方法之前，很多人喜歡用人工測試，即編譯 – 運行 – 輸入典型值 – 看程序運行結果 – 如果出錯 – 修改后再編譯……從長遠來看，這種測試方法的缺點很明顯：1、耗時耗力，每次修改代碼后都需要人工重復測試所有的典型情況；2、容易出錯、漏測，人腦太復雜，你很難記得幾個月前的那個BUG到底是什么情況，因此沒法測試，久而久之，N久前的那個BUG可能又神不知鬼不覺的重現了。相比之下，單元測試的優點就凸顯出來了，把需要測試的典型情況編寫為測試代碼，然后編譯運行即可完成自動化的測試，當發現BUG后，把它添加到測試用例，不僅可以提高測試覆蓋率，還能保證以后不會再次引入同樣的BUG，有了足夠的單元測試（覆蓋率），你就可以理直氣壯的說代碼沒問題！當然引入單元測試會在前期花費不少的時間來編寫測試代碼，但相應的也會大大減少后期的維護工作，最主要的是能可靠的提高程序的質量，所以是值得的，甚至是必要的。（如果你編譯過開源的Google Chromium瀏覽器，你會發現測試代碼就占了不少，光是編譯測試代碼就得花很長的時間）

除了上面說的優點外，單元測試還有一些其它的好處，比如幫你理清設計。一些人反對單元測試就是因為說我們的應用太復雜了，沒法做單元測試。其實不一定是應用復雜，而有可能是設計得有問題，導致了沒有可測試性。比如有些人喜歡在CXXXDialog里編寫所有的功能實現，要測試這樣的代碼，必須得創建出Dialog，可能還需要點擊，這顯然沒法做單元測試，但如果把Dialog和業務邏輯分開設計，那至少業務邏輯是可測試的（暫不討論UI的測試）。因此要做單元測試，就得設計好各個接口，保證某個接口只完成單一的功能，沒有過多的耦合依賴。

前面只是泛泛而談了一些單元測試的皮毛，鼓吹了一些優點，有興趣的自己找更詳細的資料看吧。另推薦一個Google的開源C++測試框架googletest。