单元测试之道-JAVA

单元测试,用于判断某个特定条件下,某个特定函数的行为。就是判断一个函数是否正确。
junit的断言:assertEquals  assertNull  assertSame assertTrue fail。
per-method用Setup和tearDown方法进行环境的建立和清理。
per-suite  使用TestSetup包装TestSuite,设置TestSetup的Setup和tearDown方法。
可以自定义JUnit断言,一个类继承TestCase,工程其他的类继承该类。
测试内容:Right-BICEP  right,边界条件border,反向关联Inverse,交叉检查cross,错误条件error,性能要求performence
边界条件:CORRECT  一致性conformance,有序性ordering,区间性range,引用耦合性reference,存在性existence,基数性cardinality,时间性time
Mock对象,进行替换  mock对象框架,Easy Mock
好的测试:A-TRIP 自动化automatic,彻底地thoroughly,可重复repeatable,独立的independent,专业的professional
测试代码的位置:同一目录,子目录,并行树
设计层面:使用面向测试的方法,更好的分离关注点,为测试而重构   测试类的不变性:结构化、数学不变性、数据一致性 测试驱动的设计 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
完整的中文版《单元测试之道C#版》。单元测试不但会使你的工作完成得更轻松,而且会令你的设计变得更好,甚至大大减少你花在调试上面的时间。 在我们上面的小故事里面,Pat 因为假设底层的代码是正确无误的而卷入麻烦之中,先是高层代码中使用了底层代码;然后这些高层代码又被更高层的代码所使用,如此往复。在对这些代码的行为没有任何信心的前提下,Pat 等于是在假设上面用竖立卡片堆砌了一间房子——只要将下面卡片轻轻移动,整间房子就会轰然倒塌。 当基本的底层代码不再可靠时,那么必需的改动就无法只局限在底层。虽然你可以修正底层的问题,但是这些对底层代码的修改必然会影响到高层代码,于是高层代码也连带地需要修改;以此递推,就很可能会动到更高层的代码。于是,一个对底层代码的修正,可能会导致对几乎所有代码的一连串改动,从而使修改越来越多,也越来越复杂。于是,整间由卡片堆成的房子就由此倒塌,从而使整个项目也以失败告终。 Pat 总是说:“这怎么可能呢?”或者“我实在想不明白为什么会这样”。如果你发现自己有时候也会有这种想法,那么这通常是你对自己的代码还缺乏足够信心的表现——你并不能确认哪些是工作正常的而哪些不是。 为了获得Dale 所具有的那种对代码的信心,你需要“询问”代码究竟做了什么,并检查所产生的结果是否确实和你所期望的一致。 这个简单的想法描述了单元测试的核心内涵:这个简单有效的技术就是为了令代码变得更加完美。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值