总览
这是本相对简单的书,书中采用的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.****.net/u011393781/article/details/52669772)
7. 好的测试所具有的品质(A-TRIP)
- 自动化(Automatic):自动化地调用测试和检查结果;常用的持续集成工具
- 彻底的(Thorough):测试了所有需求关注的情况;常用的代码覆盖工具
- 可重复(Repeatable):每个测试应该独立于其他所有的测试,还必须独立于环境,从而可以重复地执行,并且产生相同的结果。
- 独立的(Independent):确保一个函数只针对一样测试,并且这个测试不依赖于其他测试。
- 专业的(Professional):测试代码应该与产品代码的编码风格和编写质量相同
如何确保测试代码是正确的呢?
- 对产品代码中的Bug进行修改的时候也改进测试代码;(因为这个Bug是测试代码没有发现的)
- 在产品代码中引入Bug来验证测试代码的正确性。(确保可能会发生的错误被测试代码捕捉到了)
8. 在项目中进行测试
- 把测试代码与产品代码放在一个目录下;
- 与别人共享代码的时候,需要确保你的代码可以通过所有测试;
- 测试的时间点:
- 编写新的函数;
- 修正Bug;
- 每次成功编译之后;
- 每次对版本控制的提交;
- 持续不断地由专门的机器来运行完整的构建和测试。
- 测试别人的项目代码:其实就是维护别人的项目绝对是个大问题,同时也是个必须面对的问题。需要理性的态度(不批评别人的代码)、冷静的手段(不随便修改别人的代码)、持久的耐心(先从测试代码开始,慢慢重构项目代码,使之重新回到健康状态)、真正的智慧(知道什么样的项目应该达到什么样的目标,不执着于重构成一个完美的状态,也不简单放弃随之自生自灭。)
- 测试与评审:三个臭皮匠顶个诸葛亮,放下自我的执着,接纳各种不同的意见,才能做出令自己满意的项目。
9. 设计话题
- 面向测试的设计:不方便测试的设计不是好的设计;说明设计过于僵化或者臃肿,需要简化或者修改使之更利用未来的扩展和维护。
- 面向测试的重构:不方便测试的代码不是好的代码;说明业务混杂在一起,无法实现一个函数只针对一样测试,需要修改设计使业务分离。
- 测试类的不变性:就是对类的断言必须为真。
- 有序性。例如:sorted list类的不变性就是无论发生什么,结果都应该是有序的。
- 结构化。例如:订单系统中每个条目必须属于一个订单,一个订单拥有一个或多个条目。
- 数学不变性。例如:银行账号的的借贷必须平衡。
- 数据一致性。例如:商品总数=库存数+销售数。
- 测试驱动的设计。使你作为产品代码的用户在编码,而不是产品开发者在编码,开发结果更能反应用户的需求。
- 测试无效的参数。当你作为产品代码的用户时,你才能真正确定哪些责任应该你来承担,而哪些是不需要的。例如:无效的参数应该由哪个函数来承担检查责任呢?