2008-01-28

提高UT质量

关键字: unit test 质量
1.选择正确的粒度.不是所有的代码都要有匹配的测试用例,有些情况下可以不用写测试用例.
机器或工具生成的代码是不需要测试的.
多数的POJO是不用测试的,除非你重写了它的hashCode和equals方法.
接口和抽象类是不需要测试的.
基于现在的开发实力,我们决定不做UI层的UT.我说的UT是指通过代码做测试.

2.选择合适的Mock工具
经常使用的就是jMock和EasyMock,两者各有所长,根据你的项目环境找到合适的Mock工具.

3.提高UT的独立性.
如果UT依赖太多,表明这个UT是很粘的,bad smell.你要做出改变.用mock objects可以有效减少依赖.如果访问数据库是必要的,例如DAO实现的UT,那么最好建立一个专用的UT数据库,并制定相关的规则保证UT数据库不会被任意改动,包括数据和结构.或者就用DbUnit.

4.UT都应该是可以自动运行的.
自动运行是一件非常简单同时又非常重要的事.不需要人的干预,自动做你布置好的任务,不需要花时间和精力去安慰他鼓励他,还有什么比这更好的事情?!

5.UT可以重复运行
让你用例可以重复运行,不要写只能运行一次的用例,那没有多大的用处.重复运行代表着这个用例可以被不断地运行N次而不被打断,一旦打断就知道是你的程序出了问题.重复运行也依赖于用例的独立性.

6.UT已经完全覆盖了你的代码,根据每个bug不断补充UT的覆盖情况
仔细理解需求和设计,通过实施TDD实现代码的良好覆盖.一旦发现bug,先通过测试用例重现它,再去修复这个bug.这样你的UT覆盖就会越来越广.

7.定义合理的边界
了解输入和输出,对之进行分析,找到边界并完善测试用例.很多bug都是因为边界值引起的.

8.用一台独立的机器做CI服务器持续运行UT.
找一台机器并不是难事,不要轻易放弃.让机器做它擅长的事,让人做人擅长的事,不要搞反了.机器不会觉得累,让它持续运行编译,发布和UT.让人来做这些事只会让这个世界再多个疯子.

9.减少每个UT方法的断言
每个UT方法最好只做一个断言,如果一个方法中有了多个断言,那么每次你只能测试出一个Bug.把这些断言分散到几个方法中,可以一次运行就发现所有的bug.

这些都是我最近在团队内推行UT的心得,你有什么建议?
评论
jomper 2008-01-30
是我说错了 我闭嘴.
gigix 2008-01-30
ajoo 写道
jomper 写道
我指的是一个业务模块,而不是用mock实现几个接口.

业务模块不是用接口建模的么？还是不明白一个mock模块是什么意思。

他以为自己在说mock，其实是在说stub
我最近已经渐渐的能习惯这种随便用术语的说话方式了
ajoo 2008-01-29
jomper 写道
我指的是一个业务模块,而不是用mock实现几个接口.

业务模块不是用接口建模的么？还是不明白一个mock模块是什么意思。
jomper 2008-01-29
我指的是一个业务模块,而不是用mock实现几个接口.
ajoo 2008-01-29
jomper 写道
很多是 EasyMock不能完成的. 他只是帮你实现一些 常用功能，

这个偶咋看不明白？什么“常用功能”？
jomper 2008-01-29
很多是 EasyMock不能完成的. 他只是帮你实现一些 常用功能，而我说的是指 业务mock
samuelray 2008-01-29
如果你使用了jMock或EasyMock或其它的Mock工具,就不用去手动创建mock.
jomper 2008-01-28
整个项目在detail design阶段在出sequence diagram的时候 就是一个mock group.
模块A: mock A
模块B: mock B
...

开发的时候
实现某个模块碰到需要交互的时候不需要的其他真实模块，之需要mock.
src/java
src/testcase
src/mock

特别是模块之间 交互流程比较多，或者和硬件打交道 情况不可预知的项目尤其应该这样做。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

samuelray
搜索本博客
最近加入圈子
存档
最新评论