标签:dbunit
数据库测试:
之前写的数据库测试代码稍微有点繁杂,现在我们将这些代码进行简化一下,将备份、还原数据的方法单独写在一个类里,然后测试类继承于这个类。
代码示例:
测试类代码示例:
测试结果:
测量测试覆盖率:
测量测试覆盖率就是测量测试代码运行了多少个测试分支,如果测试代码的全部分支都被运行了,那么测试覆盖率就是100%。
打个比方就是一个猎人挖了100个不同的陷阱,猎人需要一个个的去触碰这些陷阱以确保陷阱没有问题能够捕捉到猎物,这个阶段就是测试环节。而最终猎人总共触碰了多少个陷阱,这就是测试覆盖率,猎人把所有的陷阱都触碰过了并且陷阱都没有问题的话,那么测试覆盖率就是100。如果猎人只触碰了80个陷阱,那么测试覆盖率就是80%。
如何进行测量测试覆盖呢?我们需要用到一个插件叫做cobertura,这个插件能够很好的帮助我们测量测试覆盖率,这个插件需要插入Maven的生命周期中,在执行Maven测试的时候能够运行这个插件。测试成功后这个插件会生成html文件,从这些文件中可以查看代码的测试覆盖率。
配置语法:
执行Maven测试,正在下载插件:
测试成功:
生成的html文件在这里:
右键使用web方式打开:
点击All,在这里可以查看类和包的测试覆盖率:
虽然这是个很不错的插件,但是使用的人不多,如果遇上需要测量测试覆盖率的业务,这个插件能帮很大忙。
代码习惯:
l 一般大部分情况下,进行项目的开发,都是先从功能实现的角度进行构思,先分析业务需求、绘制项目模型,然后一步步得编写实现代码,在最后项目代码开发完成后再进行相应的测试,这是普遍的项目开发习惯。
l 在此外还有一种开发方式是:先分析这个项目可能会出现的错误、bug,从而有针对性的去编写测试用例,然后再根据测试用例去编写实现代码,这种方式用得好的话可以事先避免很多代码可能出现的错误,有点逆向思维的味道。
l 除了以上两种方式之外,还有一种合作式的开发方式:一个人单独编写测试用例,分析实现代码可能出现的错误,另一个人同时分析项目业务需求和功能实现,然后再根据写好的测试用例编写实现代码。这种方式使用得当开发效率会比前两个方法要高,这种方式有点像是前两个方法的结合体。
本文出自 “zero” 博客,请务必保留此出处http://zero01.blog.51cto.com/12831981/1976744
标签:dbunit
原文地址:http://zero01.blog.51cto.com/12831981/1976744