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

软考站考试大编辑推荐:
2009年全国计算机软件水平考试报名信息汇总	2009年软考重大变革系统分析师下半年停考
2009年上半年全国计算机专业技术资格考试安排	2009年下半年全国计算机专业技术资格考试安排
2008年12月全国计算机软考水平考试真题及答案	2008年12月全国计算机软件水平考试成绩查询
2009年全国计算机软考考试大纲汇总
更多优质资料尽在考试大论坛 考试大在线题库