Junit 学习笔记

上周空闲，看完了《单元测试之道》，这里对自己的学习做个小结，以便以后查阅：

 

 

一般原则：

测试任何可能失败的地方。

测试任何已经失败的地方。

对于新加的代码，在被证明正确之前，都可能是有问题的。

至少编写和产品代码一样多的测试代码。

针对每次编译都做局部测试。

签入代码之前做全局测试。

需要回答的问题：

我如何知道代码运行是否正确呢？

我要如何对它进行测试？

还有哪些方面可能会发生错误？

这个问题是否会在其他的地方出现呢？

测试哪些方面 ：使用junit 测试的6个方面，统称为：Right-BICEP:

Right －－－ 结果是否正确？

B －－－ 是否所有的边界条件都是正确？

I －－－ 能查一下反向关联吗？

C －－－ 能用其他手段交叉检查一下结果吗？

E －－－ 你是否可以强制错误条件发生？

P －－－ 是否满足性能要求？

编写测试用例原则，correct边界条件：

conformance （一致性）－－ 值 是否和预期的一致。

Ordering（顺序性）－－一组值是该有序或者无序的。

Range（区间性）－－值是否位于合理的最小值和最大值之内。

Reference（引用 、耦合性）－－代码是否引用了一些不在代码本身控制范围之内的外部资源。

Existence（存在性）－－值是否存在（例如，是否是非null，非0，在一个集合中等等）。

Cardinatity（基数性）－－是否恰好有足够的值？

Time（相对或者绝对的时间性）－－所有事情的发生是否是有序的？是否是在正确的时刻？是否恰好及时？

环境方面的因素：

内存耗光。

磁盘用满。

时钟出问题。

网络不可用或者有问题。

系统过载。

调色板颜色数目有限。

显示分辨率过高或者过低。

0－1－n 原则

Mock对象：

真实对象具有不可确定的行为（产生不可预测的结果，如股票行情）

真实对象很难被创建

真实对象的某些行为很难触发（如网络错误）。

真实对象令程序的运行速度很慢。

真实对象有（或者是）用户界面。

测试需要询问真实对象它是如何被调用的（例如，测试可能需要验证某个回调函数是否被调用了）。

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

借助于mock对象，我们就可以解决上面提到的所有问题。在使用mock对象进行测试的时候，总共有3个步骤，分别是：

1. 使用一个接口来描述这个对象。

2. 为产品代码实现这个接口。

3. 以测试为目的，在mock对象中实现这个接口。

mock提供了所有系统功能的现成接口，所以在更多的时候，人们可能（也许吧）会使用它而不是直接调用诸如System.currentTimeMillis()这样的东西，而是躲在接口背后拥有了控制一切行为的能力。

这就是mock对象的全部；伪装出真实世界的某些部分，使你可以集中精力测试好自己编写的代码。让我们接下来看看更加复杂的例子吧。

好的测试是一个A－TPIP：

1. 自动化 (Automatic).  调用测试自动化和检查结果自动化。

2. 彻底的 (Thorough).

3. 可重复 (Repeatable).

4. 独立的 (Independent).

5. 专业的 (Professional).

在你发现bug时，所需要做的就是以下四个步骤：

1.验明bug；

2.编写一个将失败的测试来证明bug的存在。

3.修正代码，让测试通过。

4.验证所有的测试仍然可以通过（也就是，你没有在修补的时候损坏其他的测试）。

测试的频率：

1.编写新的函数    编译并运行本地的单元测试。

2.修正bug    运行测试来让bug现形；修并再次运行单元测试。

3.每次成功编译之后   运行本地的单元测试。

4.每次对版本控制的签入   运行所有的模块或者系统的单元测试。

5. 持续不断地   应当有一台专门的机器来运行完整的构建和测试。每次都应该从头开始，并且整天自动运行（要么是周期性的，要么是每当有版本控制的签入行为的时候）

编码和评审以这样的顺序进行：

1. 编写test case 和/或测试代码。

2. 评审test case 和/或测试代码。

3. 经评审修改test case 和/或测试代码。

4. 编写能通过所有测试的产品代码。

5. 评审产品代码和测试代码。

6. 在每次评审后，修改测试代码和产品代码。

在某些机器上测试失败：

这究竟是为什么呢？这些机器之间有什么区别呢？

比较明显的答案可能是下面这些资源的差异：操作系统版本号、运行库、java运行引擎、数据库驱动等。

统一使用junit 方法的setup 和 tearDown方法。