在TDD中煎熬了已有一阵子了,所谓吃得苦中苦,方为人上人.回首这段旅程,需要总结的东西很多,我只理理曾经出现在脑海中的疑问,并提供本人的对该问题的理解.以后随时补充.
☆写测试的时间比写代码的时间还多?
在有些情况下的确如此,但是不要太担心.为什么呢? 根据我的体会:
1.有了测试,你会少写很多本来不需要(初看起来应该是有用)的代码
2.写测试的过程就是在解决问题的过程,因此你会比较容易,尽早地明白你到底应该做什么.这样在写代码时,就能节省时间
3.对重构帮助很大.有了测试,你才能放心大胆的进行重构.
4.长远来看,因为TDD会促进你写出好的代码,并且你会经常的重构,因此会降低维护代价
☆需要为每个方法编写测试吗?
当然不需要.我们所写的测试必须是针对接口方法的.一般认为处理业务逻辑的方法,以及领域模型对象的关键行为是必须进行测试. 其它的一些方法需要自己把握,当然这需要经验.
我现在只是一个新手,没有啥经验.我判断某个方法是否需要测试,依据有两条:
1.是否满足我上面列出的必须测试条件
2.是否值的测试,这一条主要是心理因素,例如对某个方法感觉心里没底,那就先编写测试.
☆TDD是一种测试新技术吗?
当然不是,TDD根本就不是一项测试技术.它是一种新的开发方式,只是借助测试而已.
☆项目一开始没有采用TDD,在项目中期再引入TDD,可行吗?
一般来说不推荐在项目中期再引入TDD,这是由于TDD内在特性决定的.
1.TDD是一种新的开发方法,在开发过程中就需要你转变思想,需要在实践不断完善自己,而且它本身就具有一个较陡学习的坡度,这一点在很多文章中都提到过.因此在项目中期引入TDD,会立即拖延项目进展,对项目本身帮助也不会太大.
2.TDD在你开始写测试时,会驱动你对问题进行思考,然后持续进行功能增强和重构.在项目中期,如果你编写一个测试,这时你需要项目早期的一个组件,但是这个组件并没有满足你的测试(因为根本就没有测试).现在因为该组件有问题,测试通不过.如果这时你再为该组件编写单元测试,就失去了测试驱动开发的优势了,此时TDD的效果就大打折扣了.
当然,在没有项目压力的情况下,引入TDD是没有任何问题的.不过我还是推荐在项目开始就引入TDD是最佳选择.
☆为也存在的组件补充单元测试值得吗?
在上一问题的第二点原因中已经提到过,感觉不值得.在这种情况下,用一般的方法测试一下即可,比如java的main()方法.
☆TDD编写的测试案例是比较复杂的吗?
在TDD中,测试是一步一步演化的,需要你一直保持简单设计的理念,因此,一般测试案例是比较清晰的.如果发现你的测试非常复杂,应该是你没有抓住问题的重点或者没有掌握正确,有效的方法.