張大胖和單元測試
1.敏捷
運動張大胖的公司正在掀起一場轟轟烈烈的敏捷運動。
似乎一夜之間， 每個人的嘴邊都掛起了scrum, xp , tdd，user story 等敏捷詞匯。
公司要求， 每個開發(fā)人員都必須掌握單元測試這個非?；镜拿艚輰嵺`，為此公司還專門組織了單元測試培訓。
張大胖自然不能落后， 他熱情滿滿地參與了培訓， 在會議上了解了單元測試的各種好處, 學會了JUnit這個簡單又強大的測試工具，理解了一個測試用例執(zhí)行之前會調用"Setup"方法做必要的初始化, 執(zhí)行完畢以后會調用 “teardown”做清理。
培訓中還特別提到了如何做Mock對象， 這讓張大胖印象深刻： 原來那些不存在的或者難于new 出來的對象可以使用Mock工具(EasyMock, jmockit等) 來“造假”啊!
公司還專門定義了什么是好的單元測試：
1. 單元測試是“白盒測試”， 應該覆蓋各個分支流程、異常條件
2. 單元測試面向的是一個單元("Unit"), 是java中的一個類或者幾個類組成的單元。
3. 單元測試運行一定要快!
4. 單元測試一定是可重復執(zhí)行的
5. 單元測試之間不能有相互依賴，應該是獨立的。
6. 單元測試代碼和業(yè)務代碼同等重要， 要一并維護。
培訓結束了，張大胖信心滿滿： 寫單元測試簡直就是小菜一碟!
精明的項目經(jīng)理趁熱打鐵、不失時機對大家提出了要求： 兄弟們，我聽說隔壁組定了一個目標， 單元測試的代碼覆蓋率要達到70% ， 我們一定要超過他們， 我們的覆蓋率要達到 75% !
2.困惑
張大胖磨拳擦掌，準備大干一場 ， 他打開了Eclipse, 開始查看自己之前寫的代碼，準備全部加上單元測試用例， 搞一個代碼100%全覆蓋， 勇奪覆蓋率冠軍!
可是***個小模塊就把張大胖給難住了， 你看看這代碼， action調用service, service調用 dao, dao里都是sql， 簡單的增刪改查，這有什么可測試的?
唉，為了代碼覆蓋率，硬著頭皮寫吧，按照分層測試的原則， 測試action的時候把service給mock出來，測試service的時候把dao給mock出來......但張大胖總覺得不太對勁，總是覺得自己是在測試框架，而不是測試業(yè)務代碼。
當然，張大胖也遇到了一些有一定業(yè)務邏輯的模塊，但是這些模塊患有重度依賴癥，依賴10幾個其他模塊的接口，為了單獨測試他們，張大胖廢了九牛二虎之力，做了10多個mock對象才把依賴給解除開。
但是mock對象過多， 協(xié)調他們進入一致的狀態(tài)來正確執(zhí)行測試十分困難： 當接口1處于A狀態(tài)，并且接口2處于B狀態(tài)， 并且接口3處于C狀態(tài)..... 接口10處于X狀態(tài)時， 測試用來才能正確執(zhí)行， 唉，真是不容易啊。
一天下來， 這個mock就把張大胖弄的頭暈。
大胖感慨的想： 敏捷教練們大談單元測試的好處， 可用來展示的都是非常簡單的例子， 現(xiàn)實的代碼要復雜的多啊。
第二天便發(fā)生了狀況， 同組的小李改了業(yè)務代碼，卻忘記修改單元測試代碼，導致很多單元測試失敗，那一大片醒目的紅色讓人觸目驚心。
小李去修改單元測試，可是怎么都讀不懂大胖的測試用例，他不滿的說: ”大胖，我覺得你的測試代碼比業(yè)務代碼都要復雜啊， 你是怎么寫出來的?“
大胖委屈的說： “別說你了， 看看這么多的mock 對象， 我自己都頭暈， 這該怎么辦呢?”
小李也沒轍， 這樣下去， 別說業(yè)務代碼了， 光是維護單元測試就把人給累死了。
3.討論
他們倆人去找項目經(jīng)理訴苦， 經(jīng)理說： 有不少人都在說這個問題，我們開一個會議來討論下吧!
項目經(jīng)理召集了幾個經(jīng)驗豐富的骨干專門來討論這個問題。 他先做了一個開場白：
“我們現(xiàn)在的單元測試進行的如火如荼， 我們組做的還是非常好的， 其他組遇到的像”單元測試運行慢”， “單元測試不能重復執(zhí)行， 換一臺機器就出錯”,"單元測試互相依賴" 等常見問題我們組基本沒有， 我們遇到的主要問題有兩個：
1. 張大胖和小李反映單元測試代碼過于復雜， 難于維護， 張大胖那個mock了10多個接口的測試想必你們也看到了
2. 大家認為有些非常簡單的增刪該查沒必要去做單元測試 。
如果單元測試維護成本越來越高， 我擔心大家會慢慢的拋棄他們， 大家一塊兒來想想辦法吧”
老梁說： “我做單元測試的時間比較久了， 我認為如果測試代碼需要很復雜的Setup 才能開始測試， 那就反映了一個問題：我們的業(yè)務代碼接口設計有問題! ”
張大胖佩服的說： “老梁真厲害，一下子就看出了問題的本質， 我當時只是想著怎么把測試搞定，沒想到是業(yè)務代碼的問題”
老蔡也附和說： “說的沒錯， 簡單的單元測試誰不會啊? 關鍵還是要處理現(xiàn)實中的遺留代碼， 我們之前有些模塊的API設計確實是有問題， 看來到了重構的時候， 我們趁著這次東風把一些不好的設計提升一下， 這樣測試肯定會變的簡單。 大胖， 小李， 重構的過程基本上就是一個重新設計的過程， 這可是個學習的好機會啊”
大胖說：“ 我也了解過一些重構， 正好練習一下。 ”
大家都表示同意， 只是項目經(jīng)理為難的說： “重構可能會很費時間， 還有可以引入新的bug , 測試也要介入， 這樣的話會不會影響我們的進度啊?”
老梁說： “這也是沒辦法的事情 ，如果不重構， 不要說單元測試了， 就連我們的代碼都可能今天被貼個補丁， 明天再被貼個補丁， 慢慢的腐化下去， 越來越難以維護， ***無人能懂， 無人敢改，維護成本可是天價了。 ”
大胖說： “沒事， 為了學習 ，我愿意加班來做”
經(jīng)理贊賞的看著大胖，心說: "這孩子不錯，挺上進的， 年終考核的時候得傾斜一下"
“好吧，就這么決定” 經(jīng)理說，“大胖，相關的重構你來做， 有問題的話請教老梁和老蔡吧”
“那增刪該查到底要不要測試?”
老梁說：“我那天仔細思考了一下，這些代碼沒有邏輯， 就是一層調用一層， 我覺得單元測試必要性不大”
“如果不測試，怎么保證正確性呢? 我們的代碼覆蓋率也肯定達不到75%了” 大胖說
“沒有必要特別追求代碼覆蓋率， 要不這樣” 老蔡說，“對于這樣的代碼， 咱們就不要寫單元測試了， 還是通過自動化的功能測試來覆蓋得了!”
“嗯，我覺得這樣可行， 功能測試可以有開發(fā)寫， 也可以由測試來寫” 項目經(jīng)理說
老梁說： “同意， 還有一點建議是， 之前我們都是程序員在自己機器上跑單元測試， 以后咱們要把運行的過程加入到自動化的Build當中， 包括單元測試和功能測試，作為重要的質量保證。”
4.一年以后
經(jīng)過團隊艱苦的努力， 張大胖的項目組通過單元測試和功能測試編織起來了一張密密麻麻的安全大網(wǎng)，不管是多么微小的變動， 都有測試用例做回歸測試， 現(xiàn)在大家需要改動起代碼時比原來自信多了。
更重要的是， 關鍵的核心代碼做了重構，接口API變的越來越好，代碼易讀易維護，沒有了臟代碼的羈絆， 新需求實現(xiàn)起來也更加容易。
張大胖感慨的說： “實現(xiàn)了自動化的單元測試， 我們確實變得更敏捷了。”
當別人問他是怎么做單元測試的， 張大胖說： “告訴你吧， 關鍵就在于如何處理遺留代碼。”
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉載請通過作者微信公眾號coderising獲取授權】
