l

2010年1月23日 星期六

有 test cases 改遍天下,無 test cases 寸步難行

01/23 02:24~03:28

如果要列舉 agile methods 對於軟體開發行為模式的影響,除了 iterative and incremental (IID) 之外,最重要且影響最深遠的應該首推自動化測試了(感謝 JUnit)。幾個很重要的 agile practices,包含 refactoring 和 continuous integration,如果沒有自動化測試就『破功了』。

Teddy 本身對於自動化測試的進化路徑如下:

  1. 沒寫過(不會寫也不願意寫)自動化測試。有沒有搞錯,程式都寫不完了,哪有時間寫測試。
  2. 開始用 JUnit 寫單元測試。
  3. 用 JUnit 寫很多單元測試。
  4. 用 JUnit 寫一些整合測試。
  5. 用 JUnit 寫一些功能測試。
  6. 嘗試在 JUnit 中用 mock object framework。
  7. 很少在 JUnit 中用 mock object framework。不是不好,而是不合 Teddy 的胃口。
  8. 用 JUnit 寫很多功能測試。 
  9. 當發現 bug 時,想辦法用寫一個測試來還原這個 bug(test-driven debugging)。
  10. 三不五時想到的時候,在開發新功能時,先寫 test code 再寫 production code (玩票性質的 test-driven development)。

最近 Teddy 與同事修改專案中某個模組,增加新的功能也同時重整 (refactor) 該模組許多類別的介面。還好該模組有相當多的測試案例,所以這麼大幅度的修改,『只』產生大概 10 個左右無法立即發現的 bugs。這些 bugs 都是現有測試案例沒有涵蓋到的(廢話...),所以當 Teddy 與同事一起 pair debugging 時,我們第一步就是寫一個測試案例來暴露出這個 bug。講白話文就是寫一個一定會失敗的測試案例,當這個 bug 修正之後,這個測試案例就會成功。

這次 refactoring 主要反應了某些軟體架構上的改變,算是所謂的 big refactoring。雖然前前後後一共花了三~四天才把全部的 bugs 改完(包含寫新的測試案例),整個過程還算順利。如果沒有這些測試案例,修改的過程應該早就失控了。這種『越補越大洞』的經驗,對於廣大的鄉民們而言應該不陌生吧。

很多有心想要導入 agile methods 的人會說:『要 programmers 寫測試案例好難』,『不知道要如何開始作 test-driven development』。Teddy 的經驗是,雖然 test-driven development 是一種透過寫測試案例來達到設計程式的目的(就是 TDD 應該算 design 而不是 testing),但是除非 programmers 已經將寫測試案例當作開發系統不可分割的一部分,否則並不容易推行 TDD。如果 programmers 寫測試案例就跟『喝開水』一樣簡單與自然,那麼一不小心他們就會慢慢演化成 TDD 動物。

結論就是:不能沒有你,test cases


友藏內心獨白:這麼晚了還不睡,寫什麼部落格,小心明天被罵!

沒有留言:

張貼留言