《单元测试之道Java版——使用JUnit》读书笔记

[align=center][img]http://images.china-pub.com/ebook20001-25000/22962/shupi.jpg[/img][/align]
这个可能是到目前为止我看到的最薄的技术书了.一本专门讲用junit做测试的书籍, 但是又不是纯技术的书籍, 里面没有介绍junit如何实现, 也没有大篇幅的介绍如何使用junit, 或者介绍junit的一些高级用法, 这些统统的没有, 那么这本书都讲的什么呢, 它讲了做单元测试的一些原则, 单元测试测什么, 什么样的单元测试才是一个好测试.
这本书的一个缺点就是, 当前junit都4.x后了, 结果本书还在拿3.x说事儿, 有些不爽. 不过瑕不掩瑜. 因为很多内容(比如原则)都是超越于具体的junit版本的.很多东东拿到最新的版本下依然适用.

对于每个新写的函数, 在其他代码使用这个函数并对它形成依赖之前, 都要先做测试

一个单元测试是用于判断某个特定条件或场景下某个特定函数的行为.

执行单元测试, 是为了证明某段代码的行为确实和开发者所期望的一致

在测试某段代码是否与你期望的一致, 你需要确认: 在任何情况下, 这段代码是否都和你期望的一致.

[b]测试哪些内容:Right-BICEP[/b]
Right:结果是否正确:
B:是否所有的边界条件都是正确的?
I:能查一下反向关联吗?
C:能用其他手段交叉检查一下结果么?
E:你是否可以强制错误条件发生?
P:是否满足性能要求?
[b]上面说的感觉是鸟语, 可以无视:)[/b]

[b]好的测试应该具有的品质[/b]
[b]自动化[/b]
[b]彻底的[/b]
[b]可重复[/b]
测试不能依赖于不受力直接控制的任何外部因素
[b]独立的[/b]
测试应该是间接而且精炼的, 这意味着每个测试都应该具有很强的针对性, 并且独立于环境和其他的测试
在编写测试时, 确保你一次只测试了一样的东西
一个测试函数应该专注于产品代码中的一个函数, 或者组合起来并共同提供某一个特性的一组函数
理想情况下, 你能够在潜在的bug和测试代码之间有可追踪的对应关系. 换句话说, 当一个测试失败了, 应该立刻就可以知道代码中潜在的bug位置
"独立的"意味着没有测试依赖于任何其他的测试; 你应该可以任何时候以任何顺序运行任何单个测试.
[b]专业的[/b]
单元测试代码应该真实的, 甚至比里卖给客户的代码还要专业, 至少必须和产品代码相同的水准来编写和维护测试代码. 对于测试代码中相同的内容, 应该毫不犹豫的加以封装重用.
测试代码应该和产品代码一样多

[b]如何修正bug[/b]
[list]
[*]验明bug
[*]编写一个将失败的测试来正品bug的存在
[*]修正代码, 让测试通过
[*]验证所有的测试依然可以通过(即你在修正bug的同时没有破坏其他测试)
[/list]

应该对每次发现的bug进行总结, 以避免在项目中犯同样的错误.而不仅仅只是为修复bug而做测试.

[b]对遗留系统实施单元测试[/b]
对于已经存在的大量代码, 你可以选择为可测试的一切代码系统的添加大量的测试. 但这并不是最好的方法, 最有效的做法是只给最有可能出问题的代码进行测试, 这样才可以通过最有效的投入获得最大的回报.

[b]测试设计[/b]
如果测试代码写的非常丑陋, 甚至难于理解的话, 那么你就应该把这种情况看成一种征兆. 他暗示着你的设计可能需要修改, 改成一些设计, 知道让代码易于测试为止.

[b]测试类的不变性[/b]
改善类设计的另一个方法是:定义和验证类的不变性, 这里的不变性可以举几个例子来加以说明, 比如索引必须大于或者等于0, 索引必须小于数组的长度. 银行账号的借贷必须平衡等等.

[b]测试驱动设计[/b]
可以通过编写测试, 你现在需要把自己当成代码的用户, 而不是代码的实现者. 从这个角度来看, 你能够在接口如何被使用方面获得更多的体验, 从而更有机会来改善设计.