单元测试，测试什么？

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

<b></b>

1.right——正确

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

<b>2.b——边界条件</b>

寻找边界条件是单元测试最有价值的工作之一，因为bug一般出现在边界条件上，你常常需要考虑下面这些边界条件：

1）完全伪造或者不一直的数据进行输入

2）格式错误的数据，比如错误的url,email地址

3）空值或者不完整值，比如0,null

4)与常理相去甚远的数据，比如人有10000岁？

5）如果要求传入的是一个不允许重复数据的list，你传入一个有重复数据的看看出现什么情况

6）如果需要传入的有序的集合，你传入一个无序的看看结果

7）不按照次序地执行，比如未登录就尝试操作某功能等

对于边界条件，可以按照correct的顺序去尝试：

conformance——一致性，值是否和预期的一样

ordering——顺序性，值是否如预期的那样，有序或者无序

range——区间性，值是否处于合理的范围内

reference——引用，值是否引用了代码无法空值的外部资源

existence——值是否存在，为空？为0?不在集合内？

cardinatity——基数性，检查你的函数能否正确地计数，不多不少

time——所有的事件的发生是否按照预期的顺序，性能上满足要求？

<b>3.inverse——检查反向引用</b>

如果方法导致某个结果，尝试以另一个方法能否返回最初的状态？与原状态是否符合预期？

<b>4。cross——交叉检查</b>

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

<b>5.e——强制错误条件的产生</b>

一般我们所能想到的环境因素：

1）内存耗光

2）磁盘用满

3）时钟出问题

4）网络不可用或者有问题

5）系统过载

6）调色板颜色数目有限

7）显示分辨率过高

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

<b>6.performance——性能</b>

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

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

文章转自庄周梦蝶  ，原文发布时间5.17