落實的能力

April 21 20:46~21:32

幾年前 Teddy 還在唸書的時後，看了一篇 Continuous Testing 的 paper，大意是說，在 Eclipse 平台上，利用現在個人電腦都跑很快的特點，當使用者在 coding 的時候，Continuous Testing 系統（一個 Eclipse plug-in）就偷偷在背景模式幫 programmers 執行 unit tests，如此可以縮短 coding -> run unit testing 這個開發週期的時間。當時  Teddy 和某個學弟還改良這個想法，在 Eclipse 上面也開發了一個類似的 plug-in，雖然研究的性質居多，在實際軟體開發上面沒有真正派上什麼用場，但是覺的滿有趣的。

最近 Teddy 在思考如何縮短持續整合與建構的時間（請參考『Ten-Minute Build 』），雖然可以透過硬體升級的方法，把產生安裝軟體的時間從原本的 15 分鐘縮短到 3 分鐘，但是過這個過程是不包含執行單元測試的時間。做持續整合沒有跑單元測試其實是不對的，但是在實務上雖然 developers 都有寫單元測試，但是有些單元測試的執行時間還滿長的。最理想的作法當然是要想盡辦法用 mock objects 這一套方法來讓單元測試跑的很快，但撇開這個不談，假設鄉民就是有一堆跑起來不是很快的單元測試，那麼在實施持續整合的時候到底要不要跑這些單元測試？請鄉民們先想一想...

***

所以，為了加速數產生安裝程式的速度，有一種方法是要求 developers 至少在開發環境上（例如Eclipse）要執行單元測試，然後在持續整合系統上則不用執行，但是另外以 Robot 撰寫自動化功能測試來彌補。這些自動化功能測試每天晚上會執行一次（nigh），早上的時候有一個 倒楣的人 專門的人會去看看那些 test cases 沒有過，然後去找出問題並加以解決。

如果鄉民們喜歡的話，也可以把這些自動化功能測試範例搞成一包『自動化功能測試包』，然後用綠色軟體的方式隨時佈署到待測平台上面執行功能測試。

***

假設鄉民們的持續整合機器具有多核心的 CPU，例如有兩顆 Intel Xeon 的 CPU，每一顆 CPU 有 6 個 core，可以跑 12 個 threads，只用來執行單一的持續整合工作太浪費了。此時可以考慮在持續整合系統上面幫『執行單元測試』這件事專門建一個專案，然後當有需要的時候就去跑一下單元測試，如此一來便可同時兼顧『快速建構』與『執行單元測試』這兩件事。

其實每一次建構一個專案，除了基本的 compile 與 testing 以外，還有很多事可以做。例如，分析 test case coverage （會有點花時間），做靜態程式碼分析等等，這些都是以前很想做但是『沒時間』做的工作。現在把『執行單元測試（廣義的來講，應該是執行完整的整合工作）』這件事獨立成一個專案，這樣就有機會可以很頻繁的執行。你問為什麼？因為電腦跑很快啊，所以可以在電腦上面裝兩套持續整合系統，一套跑現有的工作（編譯並產生安裝程式），另外一套跑『完整的持續整合』，這樣就有點類似把 Continuous Testing 的概念套用在 Continuous Integration 上啦。

這樣講不知道鄉民們有沒有看懂...啊，Teddy 要準備去倒垃圾了，改天再聊。

***

友藏內心獨白：知道持續整合和落實持續整合中間的 gap 還是滿大的。