自動化單元測試 = 自動化 + 單元 + 測試
近期，本人調(diào)研了一些自動化單元測試覆蓋率是個位數(shù)的應(yīng)用，下面用實例來說明什么不是自動化單元測試，然后大概就清楚了為什么對很多開發(fā)者來說自動化單元測試那么難。
個別的Java開發(fā)者還在寫main方法，通過System.out.println()的方式來做單元測試，main方法很難被自動執(zhí)行，println的結(jié)果也需要人眼去盯著判斷，顯然這種單元測試不是自動化的。
大部分開發(fā)者懂得使用JUnit，可惜很多人用JUnit的原因只是需要一個更好用的main方法而已，他們的測試代碼里訪問了數(shù)據(jù)庫等有狀態(tài)的外部資源，根本無法重復(fù)地孤立地執(zhí)行，所以大部分工程在使用maven構(gòu)建的時候都設(shè)置了-Dmaven.test.skip=true。你沒有看錯，很多人用了JUnit這樣的自動化測試框架，但卻不想讓它自動執(zhí)行。顯然，用了JUnit，但并沒有做自動化的單元測試。
如何做好自動化單元測試？
這個更深層次的原因就是單元，既然單元測試位于組件測試之下，那單元的粒度比組件還要更小。要做好單元測試，首要條件是要有單元。如果組件內(nèi)的代碼沒有分成清晰獨立的小單元，那單元測試就無從談起。所以，三分測試，七分設(shè)計。
如果能將代碼合理地拆分成不同的單元，你就會發(fā)現(xiàn)，大部分單元，都是非常獨立的，它們不依賴數(shù)據(jù)庫等外部資源，只是一個內(nèi)存的計算，所以這部分是非常容易做自動化單元測試的。
不好做單元測試往往是膠水單元和有外部依賴的單元。而這部分代碼往往不是業(yè)務(wù)邏輯所在，代碼結(jié)構(gòu)也比較扁平，并不復(fù)雜。
所以，當你的應(yīng)用的自動化單測覆蓋率只是個位數(shù)的話，先不要急著引入測試框架工具，當務(wù)之急是做這種單元化的改造，測試那些投入產(chǎn)出效果明顯的部分。
推薦閱讀：
本文內(nèi)容不用于商業(yè)目的，如涉及知識產(chǎn)權(quán)問題，請權(quán)利人聯(lián)系SPASVO小編(021-60725088-8054)，我們將立即處理，馬上刪除。
sales@spasvo.com
