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

少于 1 分钟读完

总览

这是本相对简单的书,书中采用的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类的不变性就是无论发生什么,结果都应该是有序的。
    • 结构化。例如:订单系统中每个条目必须属于一个订单,一个订单拥有一个或多个条目。
    • 数学不变性。例如:银行账号的的借贷必须平衡。
    • 数据一致性。例如:商品总数=库存数+销售数。
  • 测试驱动的设计。使你作为产品代码的用户在编码,而不是产品开发者在编码,开发结果更能反应用户的需求。
  • 测试无效的参数。当你作为产品代码的用户时,你才能真正确定哪些责任应该你来承担,而哪些是不需要的。例如:无效的参数应该由哪个函数来承担检查责任呢?