单元测试，测试什么？

单元测试，测试什么？

我们一直强调单元测试的重要性，但是有一个问题可能没有认真去想过，测试是重要的，但是我们测试什么呢？最近重读《单元测试之道》，书中给出了答案：Right-BICEP

1.Right——正确
很显然，如果代码运行的结果与你预期的不符合，那么这段代码肯定是有问题的。需要注意的是，Right并意味着正确，因为正确只是相对你所期望的结果而言，而对于用户需求也许就是错误的。

2.B——边界条件
寻找边界条件是单元测试最有价值的工作之一，因为bug一般出现在边界条件上，你常常需要考虑下面这些边界条件：
1）完全伪造或者不一直的数据进行输入
2）格式错误的数据，比如错误的URL,Email地址
3）空值或者不完整值，比如0,null
4)与常理相去甚远的数据，比如人有10000岁？
5）如果要求传入的是一个不允许重复数据的list，你传入一个有重复数据的看看出现什么情况
6）如果需要传入的有序的集合，你传入一个无序的看看结果
7）不按照次序地执行，比如未登录就尝试操作某功能等
对于边界条件，可以按照CORRECT的顺序去尝试：
Conformance——一致性，值是否和预期的一样
Ordering——顺序性，值是否如预期的那样，有序或者无序
Range——区间性，值是否处于合理的范围内
Reference——引用，值是否引用了代码无法空值的外部资源
Existence——值是否存在，为空？为0?不在集合内？
Cardinatity——基数性，检查你的函数能否正确地计数，不多不少
Time——所有的事件的发生是否按照预期的顺序，性能上满足要求？

3.Inverse——检查反向引用
如果方法导致某个结果，尝试以另一个方法能否返回最初的状态？与原状态是否符合预期？

4。Cross——交叉检查
通过不同的方法检查一个方法产生的结果是否正确，比如用Math.sqrt方法检查自己编写的求平方根的方法是否正确。另外的方式，以一种数量去检查另一种数量，比如图书馆借出的书加上架上的书的总数是固定，可以用借出的书来检查架上的书的数量是否正确。

5.E——强制错误条件的产生

一般我们所能想到的环境因素：
1）内存耗光
2）磁盘用满
3）时钟出问题
4）网络不可用或者有问题
5）系统过载
6）调色板颜色数目有限
7）显示分辨率过高

再比如JDK版本差异，我就为这个问题头痛过：）

6.Performance——性能
每天或者每隔几天运行一下一个粗糙简单的性能测试，能够保证你不会在给用户演示的时候出现尴尬的场面。

尽管书上是讲了这么多测试这个、测试那个，我想真实的项目场景中应该根据需要采取特定的测试策略，比如你总不能对于一个单机应用需要考虑地震震断海底光缆 引发的问题。就我自己而言，因为项目组中似乎只有我对JUnit等单元测试工具充满兴趣，有经验的老程序员是自己写一个带Main方法的Test类进行测 试，而更多的人根本就不知道单元测试或者知道也不感兴趣，在没有压力的情况下，要求自己考虑这么多的测试内容，难矣。今天试用了下NUnit，感觉比 JUnit难用多了，JUnit与Eclipse的结合非常简便。