本文首發於泊浮目的掘金:https://juejin.cn/user/146860...

0. 前言

17年剛加入ZStack時，ZStack正在經歷從能用到好用的階段。這個階段會有更多的需求，對質量的要求也會更高。舉個例子，toB的產品如果在一個行業裏拓展開，一般都會想辦法拿下龍頭企業。大家都是這麼想的，你會面臨更多的競爭對手。拋去其他層面，單從技術層面來説，技術人員不僅需要提供相應的功能滿足客户需求，還需要考慮功能在不同的場景下還能夠良好的運作。

1. 前兆

週一日常週會，當研發們彙報完自己的工作後。PM開始清點當前版本遺留的bug，這時張鑫發現bug比往常多了點，測試的負責人也開始説起了近期問題的增長。這讓張鑫十分的苦惱，那時的我卻沒意識到什麼。

直到過了幾年我開始帶團隊了我才意識到這是一種前兆——系統的複雜度正在失控，這種失控在後續的迭代中會帶來越來越多的問題。

後面研發與測試單獨拉了一個小會，討論了一下目前的具體問題與細節。有人談到了自動化測試——目前的自動化測試實在太難用了，java的代碼，xml的數據配置：雖然數據和行為解耦，但寫起來只覺得囉嗦，並沒有覺得多方便，大家都不太樂意去寫。這個會開完不久後，張鑫神速的擼出了一個測試框架。

這個框架具體的實現以及一些實用tips在本文中不會再介紹，這個在ZStack的Github Repo wiki裏有介紹，我之前的文章也做過相關分析，有興趣的讀者可以自行翻閲。

2. Bug大整治

測試框架出世之後，所有開發又被拉到了一個會議室。張鑫介紹了一下自己的測試框架以及使用方法，並開始分配之後的工作：

1. 停止所有的開發工作，即日起全體開發投到測試庫中工作。
2. 將之前的java寫的測試用例全部遷到這個測試框架，如果測出bug順便修復掉。
3. 安排一個測試同學做Gitlab CI機器人，所有patch合入都要依賴這個機器人，判斷所有case跑過了才可以合入。
4. 後續版本迭代中，每一個ZStack管理平台引起的bug，合入時必須有對應的測試覆蓋。
5. 安排一些測試同學來設計一些用例，並編寫成測試代碼。

那時筆者也參與了其中，剛開始寫用例的時候，其實是十分討厭groovy的——動態類型的語言對開發者的要求相對來説高了一點，作為groovy新手是有點麻煩的——很多問題直到runtime才會報錯。但groovy又是強類型的，因此在runtime時不會跑出很奇怪的結果（JS就會），只會報錯。提供了一定方便性的同時，也沒增加多少debug成本。

強弱類型：強類型意味着確認了類型以後，如果強轉一個錯誤類型時，將會報錯（編譯期or runtime）；而弱類型則允許強轉，這種情況下則可能產生一些令人意想不到的事。

動態VS靜態類型：靜態類型需要在編譯器就確定字段的類型；而動態類型則會在runtime時根據上下問推導類型——因此我們可以在不知道方法具體細節的情況下編寫對象上的調用語句。在運行期間，對象會動態地響應方法或消息。

在後來閲讀測試框架實現時，筆者逐漸發現了動態類型的魅力——尤其是在測試場景，可以輕鬆的mock相關方法的返回值，來形成針對性的case。

這部分主要體現在groovy對於元編程的支持上。

同時，groovy還有一些語法糖並支持操作符重載——這意味着可以輕鬆的創建DSL。這讓測試代碼寫起來非常的舒服，完全沒有了之前寫java時的verbose。

3. 小結

當測試框架完全落地後，我們開始了新一輪的迭代。這次迭代過程中，經QA統計，bug趨於收斂，這意味着測試框架產生了價值：

• bug通過case one by one覆蓋，節省了測試在迴歸上的人力消耗。
• 從全局來看，避免了測試環節報bug的反覆溝通與測試，優化了業務的吞吐量。

回頭看，這個測試框架做的事用Junit+Mockito也可以做到。但一個好的測試框架，還會帶來更低的邊際成本——每個開發能夠快速的編寫測試代碼，而由於測試框架本身提供的DSL與groovy的特性，讓代碼量相比原版java的test case有效減少，從而有了更強的可維護性。

有關好的測試框架，在之後文章還會討論——比如Spock通過語義標籤以及DSL來增強測試用例的可讀性和可維護性。