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