TDD是不是以开发效率换代码质量(原标题:单元测试/TDD的成本和收益)

前端之家收集整理的这篇文章主要介绍了TDD是不是以开发效率换代码质量(原标题:单元测试/TDD的成本和收益)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
最近我在公司搞代码评审,做的过程中发现一个矛盾的问题:评审发现了问题,于是需要重构,可是重构需要有完善的单元测试做保障,而项目已接近开发结束,基本没有单元测试,结果发现的问题只能搁置,因为你很难下决心去为了完善一个东西而去冒毁坏它的风险!
这样下去,代码评审将流于形式
我意识到TDD与code review有着很紧密的联系,其实以前就听说过敏捷的十二个实践都是有内在联系的。
于是,我又转而开始宣传单元测试和TDD的必要性和好处,比如单元测试是最好的文档、单元测试是自动化的回归测试可以保护代码不被破坏、可以增强重构的信心、可以快速反馈提高开发效率……
但我的同事还是有几点担心的问题:
1、写测试需要成本
2、测试本身也可能出错
3、测试也需要维护,需求变了原来只要改一处,现在需要改两处了
4、对于一些简单的CRUD,真有必要去测吗?我鼠标点两下不就行了?
总之就是经过我的鼓吹,他们已经基本认同了从长远看TDD是值得做的,
但还是担心短期内成本会增加以至影响了当前进度。
解决这个担心,就没办法让他们在目前工期压力下做这件事情。
各位帮我分析分析吧!我已经没词儿了 所以这回讨论的焦点在短期成本和收益。 首先我认为,即便是短期看,也是值得去TDD的,这是我实践过程中的感觉: 1、写测试需要成本 这个成本不大,而且能很快的收回,比如减少了debug和集成测试的时间 2、测试本身也可能出错 测试出错说明你对程序行为的预期错了,这属于需求理解问题,无法避免 3、测试也需要维护,需求变了原来只要改一处,现在需要改两处了 我觉得这是个伪问题,因为如果你有测试套件的话,它实际上就代替了以前的详细设计文档,并且改起来更容易 4、对于一些简单的CRUD,真有必要去测吗?我鼠标点两下不就行了? 如果用了ORMapping框架,里面机关重重,因此CRUD也不简单,而且查询从来都不会简单,各种条件组合需要测的地方很多

猜你在找的设计模式相关文章