近我在公司搞代码评审，做的历程中发明一个抵触的问题：评审发明了问题，于是须要重构，可是重构须要有完美的单元测试做保证，而名目已靠近开发完结，基础没有单元测试，后果发明的问题只能放置，由于你很难下决计去为了完美一个货色而去冒损坏它的危险!
　　这样上来，代码评审将流于情势。
　　我意识到TDD与code review有着很周到的联络，其实以前据说过迅速的十二个实际都是有内在联络的。
　　于是，我又转而开端宣扬单元测试和TDD的必要性和益处，比方单元测试是好的文档、单元测试是主动化的回归测试能够掩护代码不被损坏、能够加强重构的自自信心、能够疾速反应进步开发效力……
　　但我的共事还是有几点担忧的问题：
　　1、写测试须要老本;
　　2、测试自身也能够出错;
　　3、测试也须要掩护，需求变了本来只有改一处，如今须要改两处了;
　　4、关于一些简朴的CRUD，真有必要去测吗?我鼠标点两下不行了?
　　总之是经过我的宣扬，他们已经基础认同了从久远看TDD是值得做的，但还是担忧短期内老本会增添以致影响了以落伍度。
　　不处理这个担忧，没方法让他们在目前工期压力下做这件事件。
　　所以这回探讨的焦点在短期老本和收益。
　　首先我以为，即使是短期看，也是值得去TDD的，这是我实际历程中的以为：
　　1、写测试须要老本
　　这个老本不大，而且能很快的发出，比方增添了debug和集成测试的时光;
　　2、测试自身也能够出错
　　测试出错解释你对顺序行动的预期错了，这属于需求了解问题，无法防止;
　　3、测试也须要掩护，需求变了本来只有改一处，如今须要改两处了
　　我以为这是个伪问题，由于假如你有测试套件的话，它实际上替代了以前的具体设计文档，并且改起来更随意;
　　4、关于一些简朴的CRUD，真有必要去测吗?我鼠标点两下不行了?
　　假如用了ORMapping框架，外面机关重重，因而CRUD也不简朴，而且查问素来都不会简朴，各种条件组合须要测的中央很多。