单元测试之道-深入理解JUnit

这本书是从小工到专家系列之一。这个系列有一本总纲性的《程序员修炼之道-从小工到专家》以及《版本控制之道》《单元测试之道》《项目自动化之道》三本具体软件工程技术指导书。软件工程的重要性不必多言,数据结构和算法的重要性也日渐显露,所以此后学习一定要围绕这两方面,编程也要向这两方面靠拢。

不能这样搞测试:风和日丽的一天,一辆车顺利地开过一座桥。我们必须考虑很多的车,很烂的天气。Bug出现的位置常在边界附近(0、1、N)。在定义最小值时,注意0并不是最小值。而是Integer.Min_value这个值。还有为了防止各种数据的溢出错误,一定要注意使用带验证功能的数据结构,例如温度计度数数据结构带有上下区间,不要使用系统自带的基本数据类型。

使用JUnit编写测试的一般步骤:1.准备测试条件:创建对象分配资源2.调用要测试的方法3.验证一致性4.清理各种资源

常见断言:assertEquals注意提示字符串和精度范文,assertNull,assertSame是否引用同一个对象,assertTrue,fail常用在不可能到达的地方,例如捕获异常后。

其他问题:

①    关于setUp和tearDown的调用顺序和次数问题:setUp和tearDown是每一个测试用例的方法都要调用的。

②    注意使用自定义的测试类,这样便于改动基类而不影响其它。

③    DRY原则,即不要重复你自己做过的工作。在修改中我们可以将调用委托给另外的方法,只做少量修改

六个测试部位RIGHT-BICEP:

①    Right结果是否正确

②    B边界条件是否正确:Conformance一致性:是否和预期的一致,Ordering顺序性,Range区间性:位于合理的最大最小值之间,Reference依赖性,Existence存在性,Cardinatity基数性:恰好有足够的值,Time相对或者绝对的时间性。

③    I反向关联:反向关联可以用来编写反向测试

④    C能用其他手段交叉检查一下结果么

⑤    E强制错误条件发生

⑥    P是否满足性能要求

好的测试的品质:自动化(持续构建和持续集成vs微观)、彻底的(代码覆盖工具nounit和quilt、注意BUG的28定律)、可重复、独立性(一个测试函数应该专注于代码的一个函数,建立函数和测试的对应关系)、专业的(抽取代码和封装这些属性都要用到测试代码中,代码量和测试代码量要基本相当)

关于设计的话题

①    面向设计可以更好地分离关注点:编写内向和害羞的shy code,来满足代码的封装性、正交性和耦合性。我们可以通过代码更容易测试而改善代码设计,同时更简洁易扩展和维护

②    通过定义类不变性来阐明设计意图:测试代码很丑或者难以编写时,说明你的设计需要修改,例如测试任何部分都需要系统整体运行。

③    通过TDD来改善接口:通过编写测试,把自己作为代码使用者,而非代码实现者。

④    确立和局部化验证责任

运行测试的方法:使用javacom.abc.test.TestA testAdd testSub这条CMD命令测试了TestA类下的两个测试方法。

测试的一般原则:测试任何可能失败的地方、测试任何已经失败的地方、任何新加代码,在被证明前,都可能有问题、至少编写和代码一样多的测试代码、针对每次编译都做局部测试、嵌入代码前做全局测试。

修改BUG步骤:1验证BUG、2.编写测试代码证明BUG、3修正BUG、4验证测试成功、5引入BUG证明测试通过

一些其他思考:

a)     相同的问题在其它地方么:不论是编程、写文章、做事都是这样,别人指出了一个缺点,我们必须想其他方面的问题。

b)     自定义测试骨架:自定义测试骨架,可以把自己的测试架构在可定制的基础上,方便之后操作。

c)     积累的关键在于反思与回顾,不在于存储的积累。不要只做不想

一些资源:Ant跨平台构建工具、Easy-Mock(测试中使用Mock对象的简单方法)、Nounit(图形化向你展示你项目中多少方法被测试和测试程度)、Quilt(代码覆盖)。

关于JUnit4的改进:不用继承TestCase类。测试方法不用必须加Test前缀了。增加了BeforeClass和AfterClass用于一些类规模的资源初始化和清除工作。使用@可以定义所有方法,不用拘泥固定方法名。可以测试异常,取代原来的fail方法。如@Test(expected=ArithmeticException.class)。可以简单的进行性能测试,超时参数可以简单测试。@Test(timeout=500)。为了JUnit4的测试代码在JUnit3环境下运行,可以使用JUnit4TestAdapter来封装。但方法存疑

参考文献

1.      JUnit工具使用 

2.      Eclipse下用Ant运行JUnit 

3.      理解JUnit

完整的中文版《单元测试之道C#版》。单元测试不但会使你的工作完成得更轻松,而且会令你的设计变得更好,甚至大大减少你花在调试上面的时间。 在我们上面的小故事里面,Pat 因为假设底层的代码是正确无误的而卷入麻烦之中,先是高层代码中使用了底层代码;然后这些高层代码又被更高层的代码所使用,如此往复。在对这些代码的行为没有任何信心的前提下,Pat 等于是在假设上面用竖立卡片堆砌了一间房子——只要将下面卡片轻轻移动,整间房子就会轰然倒塌。 当基本的底层代码不再可靠时,那么必需的改动就无法只局限在底层。虽然你可以修正底层的问题,但是这些对底层代码的修改必然会影响到高层代码,于是高层代码也连带地需要修改;以此递推,就很可能会动到更高层的代码。于是,一个对底层代码的修正,可能会导致对几乎所有代码的一连串改动,从而使修改越来越多,也越来越复杂。于是,整间由卡片堆成的房子就由此倒塌,从而使整个项目也以失败告终。 Pat 总是说:“这怎么可能呢?”或者“我实在想不明白为什么会这样”。如果你发现自己有时候也会有这种想法,那么这通常是你对自己的代码还缺乏足够信心的表现——你并不能确认哪些是工作正常的而哪些不是。 为了获得Dale 所具有的那种对代码的信心,你需要“询问”代码究竟做了什么,并检查所产生的结果是否确实和你所期望的一致。 这个简单的想法描述了单元测试的核心内涵:这个简单有效的技术就是为了令代码变得更加完美。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

gongqingkui

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值