Java, Only Java!

统计

留言簿(19)

积分与排名

好友空间

文档技巧

阅读排行榜

评论排行榜

《单元测试之道Java版》的读书笔记

  • 总览
  • 第2章 首个单元测试
  • 第3章 使用JUnit编写测试
  • 4. 测试什么?
  • 5.CORRECT(正确的)边界条件
  • 6.使用Mock对象
  • 7. 好的测试所具有的品质(A-TRIP)
  • 8. 在项目中进行测试
  • 9. 设计话题

      总览

      这是本相对简单的书,书中采用的JUnit的版本也是旧的,但是在新的JUnit4下稍做修改依然可以运行。重要的是通过这本书了解JUnit在Java的单元测试中是如何使用的。

      第2章 首个单元测试

      计划你的测试:测试不是无中生有的,也不是意想天开的。是根据需要一点点添加的,帮助自己尽早地发现思考上的误区。参看这章给出的例子,原来理所当然正确的,结果不一定是正确的。

      第3章 使用JUnit编写测试

      3.1 构建单元测试

      测试代码必须要做的几件事情:

      • 准备测试的条件(创建对象、分配资源等等)
      • 调用测试的方法
      • 验证测试方法的行为与期望是否相符
      • 测试结束后清理现场(释放资源等等)

        3.2 JUnit的各种断言

        断言:JUnit提供的辅助函数,帮助你确认被测试函数是否正确运行。

      后面还介绍了(3.5 JUnit的自定义断言)

      3.3 JUnit框架

      这章是基于JUnit3.x写的,建议了解就可以了,因为JUnit4的变化较大,使用也更方便直观,因此直接参考JUnit4的帮助

      框架运行顺序 对应于标签
      setUpBeforeClass() @BeforeClass
         
      setUp() @Beofre
      testMethod1()  
      tearDown() @After
         
      setUp() @Before
      testMethod2()  
      tearDown() @After
         
      tearDownAfterClass() @AfterClass

      4. 测试什么?

      6个需要测试的地方(Right-BICEP):

      • Right:结果是否正确(Right);
      • B:边界(Boundary)条件是否正确(CORRECT);参考第5章
      • I:能否检查反向(Inverse)关系;
      • C:进行交叉检查(Cross-Check)的其他手段;
      • E:强制错误(Error)条件发生;使用Mock对象实现,参考第6章
      • P:满足性能(Performance)的要求。

      测试内容较多时,可以使用测试数据文件进行准备。但是使用文件后就没有测试代码看起来那么直观了,因此除非测试内容非常复杂,否则没有必要采用这样的方式。并且如果测试文件出现错误(作者书中就出现了数据错误),还会导致测试不通过,增加了维护的成本。

      5.CORRECT(正确的)边界条件

      • 一致性(Conformance):值是否符合预期的格式;
      • 有序性(Ordering):一组值是否符合对排序的要求(有序性、无序性);
      • 区间性(Range):值是否在合理取值范围内(在最小值与最大值之间);
      • 引用(Reference)-耦合性:代码是否引用了不受代码本身直接控制的外部因素;
      • 存在性(Existence):值是否存在(例如:非NULL,非零,包含于某个集合等等)
      • 基数性(Cardinality):是否恰好有足够的值;(也称为集合的势,即集合里面包含的元素个数)
      • 时间性(Time)-绝对时间和相对时间:所有的事情是否按照顺序发生?是否在正确的时间发生?是否及时发生?

      6.使用Mock对象

      Mock对象解决的问题:

      • 真实对象具有不可确定的行为(如:股票行情);
      • 真实对象很难被创建;
      • 真实对象的某些行为很难被触发(如:网络错误);
      • 真实对象令程序的运行速度很慢;
      • 真实对象有用户界面或者就是用户界面;
      • 真实对象需要被询问它是如何被调用的(如:验证某个回调函数是否被调用);
      • 真实对象实际上不存在(如:其他开发小组的接口、或者某个没有的硬件产品)。

      Mock对象解决的步骤:

      • 使用一个接口来描述这个对象;
      • 为产品代码实现这个接口;
      • 以测试为目的,在Mock对象中实现这个接口。

      注:这里的Mock不是网上已经形成框架的Mock工具,是Mock的实现原理。作者推荐的Mock工具是EasyMock。其他的Mock工具可以参考《[使用Mock进行单元测试]》(https://blog.csdn.net/u011393781/article/details/52669772)

      7. 好的测试所具有的品质(A-TRIP)

      • 自动化(Automatic):自动化地调用测试和检查结果;常用的持续集成工具
      • 彻底的(Thorough):测试了所有需求关注的情况;常用的代码覆盖工具
      • 可重复(Repeatable):每个测试应该独立于其他所有的测试,还必须独立于环境,从而可以重复地执行,并且产生相同的结果。
      • 独立的(Independent):确保一个函数只针对一样测试,并且这个测试不依赖于其他测试。
      • 专业的(Professional):测试代码应该与产品代码的编码风格和编写质量相同

      如何确保测试代码是正确的呢?

      • 对产品代码中的Bug进行修改的时候也改进测试代码;(因为这个Bug是测试代码没有发现的)
      • 在产品代码中引入Bug来验证测试代码的正确性。(确保可能会发生的错误被测试代码捕捉到了)

      8. 在项目中进行测试

      • 把测试代码与产品代码放在一个目录下;
      • 与别人共享代码的时候,需要确保你的代码可以通过所有测试;
      • 测试的时间点:
        • 编写新的函数;
        • 修正Bug;
        • 每次成功编译之后;
        • 每次对版本控制的提交;
        • 持续不断地由专门的机器来运行完整的构建和测试。
      • 测试别人的项目代码:其实就是维护别人的项目绝对是个大问题,同时也是个必须面对的问题。需要理性的态度(不批评别人的代码)、冷静的手段(不随便修改别人的代码)、持久的耐心(先从测试代码开始,慢慢重构项目代码,使之重新回到健康状态)、真正的智慧(知道什么样的项目应该达到什么样的目标,不执着于重构成一个完美的状态,也不简单放弃随之自生自灭。)
      • 测试与评审:三个臭皮匠顶个诸葛亮,放下自我的执着,接纳各种不同的意见,才能做出令自己满意的项目。

      9. 设计话题

      • 面向测试的设计:不方便测试的设计不是好的设计;说明设计过于僵化或者臃肿,需要简化或者修改使之更利用未来的扩展和维护。
      • 面向测试的重构:不方便测试的代码不是好的代码;说明业务混杂在一起,无法实现一个函数只针对一样测试,需要修改设计使业务分离。
      • 测试类的不变性:就是对类的断言必须为真。
        • 有序性。例如:sorted list类的不变性就是无论发生什么,结果都应该是有序的。
        • 结构化。例如:订单系统中每个条目必须属于一个订单,一个订单拥有一个或多个条目。
        • 数学不变性。例如:银行账号的的借贷必须平衡。
        • 数据一致性。例如:商品总数=库存数+销售数。
      • 测试驱动的设计。使你作为产品代码的用户在编码,而不是产品开发者在编码,开发结果更能反应用户的需求。
      • 测试无效的参数。当你作为产品代码的用户时,你才能真正确定哪些责任应该你来承担,而哪些是不需要的。例如:无效的参数应该由哪个函数来承担检查责任呢?
    • posted on 2019-01-16 17:57 zYx.Tom 阅读(44) 评论(0)  编辑  收藏 所属分类: 7.学习日志


      只有注册用户登录后才能发表评论。


      网站导航: