如果要列舉 agile methods 對於軟體開發行為模式的影響，除了 iterative and incremental (IID) 之外，最重要且影響最深遠的應該首推自動化測試了（感謝 JUnit）。幾個很重要的 agile practices，包含 refactoring 和 continuous integration，如果沒有自動化測試就『破功了』。
Teddy 本身對於自動化測試的進化路徑如下：
- 沒寫過（不會寫也不願意寫）自動化測試。有沒有搞錯，程式都寫不完了，哪有時間寫測試。
- 開始用 JUnit 寫單元測試。
- 用 JUnit 寫很多單元測試。
- 用 JUnit 寫一些整合測試。
- 用 JUnit 寫一些功能測試。
- 嘗試在 JUnit 中用 mock object framework。
- 很少在 JUnit 中用 mock object framework。不是不好，而是不合 Teddy 的胃口。
- 用 JUnit 寫很多功能測試。
- 當發現 bug 時，想辦法用寫一個測試來還原這個 bug（test-driven debugging）。
- 三不五時想到的時候，在開發新功能時，先寫 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。
友藏內心獨白：這麼晚了還不睡，寫什麼部落格，小心明天被罵！
沒有留言:
張貼留言