提高UT质量

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的心得,你有什么建议?

你可能感兴趣的:(DAO,数据结构,UI,TDD)