最近我在公司搞代碼評審,做的歷程中發明一個抵觸的問題:評審發明了問題,于是須要重構,可是重構須要有完美的單元測試做保證,而名目已靠近開發完結,基礎沒有單元測試,后果發明的問題只能放置,由于你很難下決計去為了完美一個貨色而去冒損壞它的危險!
這樣上來,代碼評審將流于情勢。
我意識到TDD與code review有著很周到的聯絡,其實以前就據說過迅速的十二個實際都是有內在聯絡的。
于是,我又轉而開端宣揚單元測試和TDD的必要性和益處,比方單元測試是最好的文檔、單元測試是主動化的回歸測試能夠掩護代碼不被損壞、能夠加強重構的自自信心、能夠疾速反應進步開發效力……
但我的共事還是有幾點擔憂的問題:
1、寫測試須要老本;
2、測試自身也能夠出錯;
3、測試也須要掩護,需求變了本來只有改一處,如今須要改兩處了;
4、關于一些簡樸的CRUD,真有必要去測嗎?我鼠標點兩下不就行了?
總之就是經過我的宣揚,他們已經基礎認同了從久遠看TDD是值得做的,但還是擔憂短期內老本會增添以致影響了以落伍度。
不處理這個擔憂,就沒方法讓他們在目前工期壓力下做這件事件。
所以這回探討的焦點在短期老本和收益。
首先我以為,即使是短期看,也是值得去TDD的,這是我實際歷程中的以為:
1、寫測試須要老本
這個老本不大,而且能很快的發出,比方增添了debug和集成測試的時光;
2、測試自身也能夠出錯
測試出錯解釋你對順序行動的預期錯了,這屬于需求了解問題,無法防止;
3、測試也須要掩護,需求變了本來只有改一處,如今須要改兩處了
我以為這是個偽問題,由于假如你有測試套件的話,它實際上就替代了以前的具體設計文檔,并且改起來更隨意;
4、關于一些簡樸的CRUD,真有必要去測嗎?我鼠標點兩下不就行了?
假如用了ORMapping框架,外面機關重重,因而CRUD也不簡樸,而且查問素來都不會簡樸,各種條件組合須要測的中央很多。
歡送大家宣布本人的想法和看法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/