Unit test 的美麗與哀愁



Unit test (單元測試) 在我剛開始加入團隊的時候,有寫過一陣子。那時候使用的是內部人員自己開發的 framework。當時寫 unit test 的方法可以說相當原始,我們沒有特別去研究 unit test 可以怎麼作,stub 或 mock 更是沒有研究過的議題。大家就只是很努力地在每個模組完成後,補完大部分可能的 test cases。但是久而久之,隨著專案越來越大,架構越來越複雜後,寫 unit test 變成一個令人沮喪的活動,至少當時對我而言是這樣。原因是甚麼?

多年後,我在團隊中又剛好擔任到導入 unit test 的第一線角色。現在因為開發經驗比較豐富,對於測試應該怎麼寫,或是寫 unit test 的人應該專注於哪一部分有了一點點的感覺。在我還是個懵懵懂懂的 RD 時,覺得每次寫一個新模組的 unit test,前置大概要花好幾個小時,在寫一些該模組與其他元件「假」互動的部分,例如與資料庫溝通的模組,透過網路傳送訊息的類別,跟串流伺服器傳輸影音的函式庫。因此,寫久了會問自己,到底是在寫單元測試還是在寫假類別的程式。

[圖片來源: www.wowwiki.com]
在這一次的 unit test 導入計畫中,我們選用了 Google C++ Testing Framework,這部分其實跟之前試用過的 boost 中的 unit test framework 大同小異。同時我們也使用了 Google C++ Mocking Framework,我花了一天的時間閱讀了相關基礎文件後,頓時有種為什麼以前要花時間寫那些「假」互動。原來以前花很多時間在做的事情,使用 framework 只要幾分鐘的時間就完成了,也因此寫 unit test 的人可以真正的思考測試的流程或是設計測試的不同案例。我為了讓實際開發者能專注於如何寫 test cases,也寫了一些包裝過的 utility,期望讓大家寫 unit test 時不要有沮喪的感覺。

從目前的狀況看來,我們只是「有」了 unit test,但是我們還沒有思考覆蓋率,或是維護的問題,持續改善這一部分將是我們要繼續努力的地方。好消息是,我們的 CI 已經整合了 unit test 的部分,這多多少少也會鼓勵大家寫 unit test。只有當 RD 覺得 unit test 很好用時,他們才會願意花時間且認真的撰寫 unit test。我本人也不例外 XD

0 comments