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