關于單元測試/TDD的成本和收益的一些想法
發布時間：2012-07-19 共1頁
最近我在公司搞代碼評審，做的過程中發現一個矛盾的問題：評審發現了問題，于是需要重構，可是重構需要有完善的單元測試做保障，而項目已接近開發結束，基本沒有單元測試，結果發現的問題只能擱置，因為你很難下決心去為了完善一個東西而去冒毀壞它的風險！
這樣下去，代碼評審將流于形式。
我意識到TDD與code review有著很緊密的聯系，其實以前就聽說過敏捷的十二個實踐都是有內在聯系的。
于是，我又轉而開始宣傳單元測試和TDD的必要性和好處，比如單元測試是最好的文檔、單元測試是自動化的回歸測試可以保護代碼不被破壞、可以增強重構的信心、可以快速反饋提高開發效率……
但我的同事還是有幾點擔心的問題：
1、寫測試需要成本；
2、測試本身也可能出錯；
3、測試也需要維護，需求變了原來只要改一處，現在需要改兩處了；
4、對于一些簡單的CRUD，真有必要去測嗎？我鼠標點兩下不就行了？
總之就是經過我的鼓吹，他們已經基本認同了從長遠看TDD是值得做的，但還是擔心短期內成本會增加以至影響了當前進度。
不解決這個擔心，就沒辦法讓他們在目前工期壓力下做這件事情。
所以這回討論的焦點在短期成本和收益。
首先我認為，即便是短期看，也是值得去TDD的，這是我實踐過程中的感覺：
1、寫測試需要成本
這個成本不大，而且能很快的收回，比如減少了debug和集成測試的時間；
2、測試本身也可能出錯
測試出錯說明你對程序行為的預期錯了，這屬于需求理解問題，無法避免；
3、測試也需要維護，需求變了原來只要改一處，現在需要改兩處了
我覺得這是個偽問題，因為如果你有測試套件的話，它實際上就代替了
以前的詳細設計文檔，并且改起來更容易；
4、對于一些簡單的CRUD，真有必要去測嗎？我鼠標點兩下不就行了？
如果用了ORMapping框架，里面機關重重，因此CRUD也不簡單，而且查詢從來都不會簡單，各種條件組合需要測的地方很多。
歡迎大家發表自己的想法和意見。
這樣下去，代碼評審將流于形式。
我意識到TDD與code review有著很緊密的聯系，其實以前就聽說過敏捷的十二個實踐都是有內在聯系的。
于是，我又轉而開始宣傳單元測試和TDD的必要性和好處，比如單元測試是最好的文檔、單元測試是自動化的回歸測試可以保護代碼不被破壞、可以增強重構的信心、可以快速反饋提高開發效率……
但我的同事還是有幾點擔心的問題：
1、寫測試需要成本；
2、測試本身也可能出錯；
3、測試也需要維護，需求變了原來只要改一處，現在需要改兩處了；
4、對于一些簡單的CRUD，真有必要去測嗎？我鼠標點兩下不就行了？
總之就是經過我的鼓吹，他們已經基本認同了從長遠看TDD是值得做的，但還是擔心短期內成本會增加以至影響了當前進度。
不解決這個擔心，就沒辦法讓他們在目前工期壓力下做這件事情。
所以這回討論的焦點在短期成本和收益。
首先我認為，即便是短期看，也是值得去TDD的，這是我實踐過程中的感覺：
1、寫測試需要成本
這個成本不大，而且能很快的收回，比如減少了debug和集成測試的時間；
2、測試本身也可能出錯
測試出錯說明你對程序行為的預期錯了，這屬于需求理解問題，無法避免；
3、測試也需要維護，需求變了原來只要改一處，現在需要改兩處了
我覺得這是個偽問題，因為如果你有測試套件的話，它實際上就代替了
以前的詳細設計文檔，并且改起來更容易；
4、對于一些簡單的CRUD，真有必要去測嗎？我鼠標點兩下不就行了？
如果用了ORMapping框架，里面機關重重，因此CRUD也不簡單，而且查詢從來都不會簡單，各種條件組合需要測的地方很多。
歡迎大家發表自己的想法和意見。
|
|
