单元测试(开篇)

前言

要做单元测试，注定少不了单元测试框架和Mock框架.本文选择Junit +Mockito来讨论。先解释一下单元测试和Mock的简单概念.

单元测试：测试某一个单元的程序是否和预期的一致

Mock：Mock通常是指，在测试一个对象A时，A依赖B，我们构造一些假的对象来模拟与A之间的交互，而这些Mock对象的行为是我们事先设定且符合预期。通过这些Mock对象来测试A在正常逻辑，异常逻辑或压力情况下工作是否正常。如下图所示：

为什么选择Junit作为单元测试框架？

 Junit是使用最广泛的单元测试工具，Junit4以后的版本，在主要的功能上，已经相差不大，相比TestNG，Junit不支持重新运行失败机制.但参数化，分组等特性目前已经支持.

下面这个Junit4和TestNG的比较文章，虽然比较旧，但可以作为参考：

 JUnit4 与 TestNG 的对比 http://www.ibm.com/developerworks/cn/java/j-cq08296

 Junit Wiki https://github.com/junit-team/junit/wiki

 

Junit概述 

主要包括三大部分：

1、用于检测预期结果：Assertions
2、共享测试数据：Test Fixtures
3、运行测试： Test Runners

整体架构如下：

 

 

相关概念：

 

TestCase	对测试目标进行测试的方法与过程集合，可称为测试用例
TestSuite	测试TestCase的集合，可容纳多个TestCase，将其称作测试包
TestResult	测试结果的描述与记录
TestListener	测试过程中的事件监听者
TestFailure	每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素
AssertionFailedError	JUnit 中的出错异常

  

什么选择Mockito？

Mockito最明显的一个特点是API更人性化.详细比较如下：

Java主流Mock框架功能比较

语法比较：

详情见：Java Mock Frameworks Comparison http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

 

更多详情参考：

Mockito https://github.com/mockito/mockito

 

Mock适用场景

典型适合Mock的一些场景：

1、真实对象具有不可确定的行为，产生不可预测的结果

2、真实对象很难被创建(比如具体的web容器)

3、真实对象的某些行为很难触发(比如网络错误)

4、真实情况令程序的运行速度很慢

5、真实对象有用户界面

6、测试需要询问真实对象它是如何被调用的(比如测试可能需要验证某个回调函数是否被调用了)

7、真实对象实际上并不存在(当需要和其他开发小组，或者新的硬件系统打交道的时候，这是一个普遍的问题)

 

mock点选择

因为Mock会引入很多工作量，所以不是Mock对象越多越好
一些常用点：
1、网络交互：如果两个被测模块之间是通过网络进行交互的，如RPC
2、外部资源：比如文件系统、数据源，如果被测对象对此类外部资源依赖性非常强，而其行为的不可预测性很可能导致测试的随机失败。
3、UI：因为UI很多时候都是用户行为触发事件，系统本身只是对这些触发事件进行相应，对这类UI做Mock，往往能够实现很好的收益，很多基于关键字驱动的框架都是基于UI进行Mock的