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