1.[b]选择正确的粒度[/b].不是所有的代码都要有匹配的测试用例,有些情况下可以不用写测试用例.
机器或工具生成的代码是不需要测试的.
多数的POJO是不用测试的,除非你重写了它的hashCode和equals方法.
接口和抽象类是不需要测试的.
基于现在的开发实力,我们决定不做UI层的UT.我说的UT是指通过代码做测试.
2.[b]选择合适的Mock工具[/b]
经常使用的就是jMock和EasyMock,两者各有所长,根据你的项目环境找到合适的Mock工具.
3.[b]提高UT的独立性[/b].
如果UT依赖太多,表明这个UT是很粘的,bad smell.你要做出改变.用mock objects可以有效减少依赖.如果访问数据库是必要的,例如DAO实现的UT,那么最好建立一个专用的UT数据库,并制定相关的规则保证UT数据库不会被任意改动,包括数据和结构.或者就用DbUnit.
4.[b]UT都应该是可以自动运行的[/b].
自动运行是一件非常简单同时又非常重要的事.不需要人的干预,自动做你布置好的任务,不需要花时间和精力去安慰他鼓励他,还有什么比这更好的事情?!
5.[b]UT可以重复运行[/b]
让你用例可以重复运行,不要写只能运行一次的用例,那没有多大的用处.重复运行代表着这个用例可以被不断地运行N次而不被打断,一旦打断就知道是你的程序出了问题.重复运行也依赖于用例的独立性.
6.[b]UT已经完全覆盖了你的代码[/b],根据每个bug不断补充UT的覆盖情况
仔细理解需求和设计,通过实施TDD实现代码的良好覆盖.一旦发现bug,先通过测试用例重现它,再去修复这个bug.这样你的UT覆盖就会越来越广.
7.[b]定义合理的边界[/b]
了解输入和输出,对之进行分析,找到边界并完善测试用例.很多bug都是因为边界值引起的.
8.[b]用一台独立的机器做CI服务器持续运行UT[/b].
找一台机器并不是难事,不要轻易放弃.让机器做它擅长的事,让人做人擅长的事,不要搞反了.机器不会觉得累,让它持续运行编译,发布和UT.让人来做这些事只会让这个世界再多个疯子.
9.[b]减少每个UT方法的断言[/b]
每个UT方法最好只做一个断言,如果一个方法中有了多个断言,那么每次你只能测试出一个Bug.把这些断言分散到几个方法中,可以一次运行就发现所有的bug.
这些都是我最近在团队内推行UT的心得,你有什么建议?
机器或工具生成的代码是不需要测试的.
多数的POJO是不用测试的,除非你重写了它的hashCode和equals方法.
接口和抽象类是不需要测试的.
基于现在的开发实力,我们决定不做UI层的UT.我说的UT是指通过代码做测试.
2.[b]选择合适的Mock工具[/b]
经常使用的就是jMock和EasyMock,两者各有所长,根据你的项目环境找到合适的Mock工具.
3.[b]提高UT的独立性[/b].
如果UT依赖太多,表明这个UT是很粘的,bad smell.你要做出改变.用mock objects可以有效减少依赖.如果访问数据库是必要的,例如DAO实现的UT,那么最好建立一个专用的UT数据库,并制定相关的规则保证UT数据库不会被任意改动,包括数据和结构.或者就用DbUnit.
4.[b]UT都应该是可以自动运行的[/b].
自动运行是一件非常简单同时又非常重要的事.不需要人的干预,自动做你布置好的任务,不需要花时间和精力去安慰他鼓励他,还有什么比这更好的事情?!
5.[b]UT可以重复运行[/b]
让你用例可以重复运行,不要写只能运行一次的用例,那没有多大的用处.重复运行代表着这个用例可以被不断地运行N次而不被打断,一旦打断就知道是你的程序出了问题.重复运行也依赖于用例的独立性.
6.[b]UT已经完全覆盖了你的代码[/b],根据每个bug不断补充UT的覆盖情况
仔细理解需求和设计,通过实施TDD实现代码的良好覆盖.一旦发现bug,先通过测试用例重现它,再去修复这个bug.这样你的UT覆盖就会越来越广.
7.[b]定义合理的边界[/b]
了解输入和输出,对之进行分析,找到边界并完善测试用例.很多bug都是因为边界值引起的.
8.[b]用一台独立的机器做CI服务器持续运行UT[/b].
找一台机器并不是难事,不要轻易放弃.让机器做它擅长的事,让人做人擅长的事,不要搞反了.机器不会觉得累,让它持续运行编译,发布和UT.让人来做这些事只会让这个世界再多个疯子.
9.[b]减少每个UT方法的断言[/b]
每个UT方法最好只做一个断言,如果一个方法中有了多个断言,那么每次你只能测试出一个Bug.把这些断言分散到几个方法中,可以一次运行就发现所有的bug.
这些都是我最近在团队内推行UT的心得,你有什么建议?
552

被折叠的 条评论
为什么被折叠?



