Michael Feather提出單元測試的規則︰一個測試不能算是單元測試,如果它:
- 跟資料庫溝通
- 透過網路跟外界溝通
- 碰了檔案系統
- 不能跟其他單元測試同時跑
- 要你對環境做特別的事才能跑,像是編輯設定檔
後來我慢慢了解到,用Test-Driven Development(TDD)開發,會大幅改變程式碼的設計與風格。會做很多decoupling。我們以前"單元測試"的問題,不在"測試",而在被測的"單元"。我們的class常常要引用很難建構的資料庫物件,關係糾纏在一起,而其實應該可以把關鍵的邏輯獨立切開。先前我們最常遇到三類問題︰1. GUI、2. 資料庫,以及3. 設定檔。我們的測試沒辦法涵蓋第一項,沒辦法避開二三項。
推薦Dright介紹TDD的系列文章Dloop,尤其是DLoop 8。這裡有舉例說明GUI要如何做單元測試。作者也提供一個很珍貴的親身經驗︰用TDD開發,也就是先寫test case再實做,會自然產生Inversion of Control的設計。如果用傳統方法直接實做,反而不容易做這種反向思考。
4 則留言:
推推~
不過整合測試的自動化又應該做在那一層 ? 光UI 的自動化不太夠用的樣子噢
自動測試後續還會陸續推出相關的posts,請期待。只是寫測試這部份像是寫乾坤大挪移第七重一樣,自己沒練到那裡,只能寫出自己覺得應該是怎麼樣練。希望不會發展成聖火令上的邪門武功。
就算是聖火令上的武功,
也是"雖不中,亦不遠矣"
乾坤大挪移後面的武功,也是僅憑想像,而沒有經過驗證的....^^
唉呀,一個多月前開出的支票,到現在還沒兌現。真是要更加油了。
張貼留言