Ruby实践TDD的一些经验之谈
在实践TDD的过程中,使用了一些Ruby TDD框架,经过一番选择,最终选择了Test::Unit,实际上Test::Unit是一个较老的框架.
列举TDD中要解决的一些实践性问题
- 执行时长,这个很重要,否则CI是一件痛苦的事
- 编写效率,这个重要性同等,选择Ruby正是这个原因
- 可读性,在Ruby这已经算是不错了
- 可编程性,TDD可不是DSL能干的事,使用编程语言来支撑才是首选.如果使用的DSL,个人觉得是一种灾难
- 执行方式定制化,TDD是一种标准的工业级产品,但是如果执行方式无法定制化,应用场景就有些局限性.Rake可以适当的解决这个问题
- 断言语法的丰富性,丰富的具有语义的断言语法,不但可以节省代码,而且还可以提高可读性.目前在Ruby的测试框架中并没有太优秀的.好在Ruby动态语言的特性,非常容易扩展.
实践后的感受
在实践过程中,我使用过,rspec,testunit,rspec,rake下面分别来谈谈几个工具的感受
rspec
在使用Bundle生产GEM的时候,默认会生成Rspec,似乎describe系的DSL已经成为主流,但是实践过程中,发现太多不好用的地方,下面以Ruby中的Rspec为例一一列列举
- 语法结构太过死板,如it 不能嵌套 it
- 测试复用困难,shared_examples只能在describe外部定义,无法接受describe的上下文,不可接收变量,只可接收实参
- 增加高级特性后,可读性急剧下降,如果不信的话,可以读下文档的示例代码.
- 可编程性太差,除了Ruby的语法,其他特性使用起来太难
总结下,Rspec适合使用在GEM这样的工具上,测试场景比较简单,工程项目不建议使用
minitest
minitest看上去是可以对Test::Unit的升级,但是实践后发现,除了对Reporter进行优化外,没有太实质的提升,而且支持的断言语法也大大减少.可能真的是把Test给mini了.既然这样也就没有选择的必要了.
testunit
基本的TDD需求已经可以满足,对于断言部分,还是太少,写起来会比较类,不过因为是动态语言的关系,自己也扩展了不少.因此目前来说,没有更好的选择.
Rake
Rake的引入,可以解决测试执行的单调.multitask可以支持多线程并行测试,可以极大的增加测试效率.并且可以配置一些默认参数,可以让测试执行更简单.
为什么选择Ruby
- 开发效率高
- 可读性强
- 支持多线程
- GEM多