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