单元测试应该测试什么？

原帖地址：http://blog.csdn.net/liliangzhao/article/details/1944447

单元测试应该测试什么？——Right-BICEP

Right——结果是否正确？

B——是否所有的边界条件都是正确的?

I——能查一下反响关联吗？

C——能用其它手段交叉检查一下吗?

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

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

结果是否正确

这 个最简单不过了，就是看程序运行之后的结构和文档是否一致。当然可能很多的时候一个方法没有很完整的文档描述它，那至少也应该有简单的文字描述，否则没有 判断是否正确的依据了。一个原则是：对于验证被测方法是否正确的这件事情，如果某些做法能够使它变得更加容易，那么就采纳它吧。

边界条件CORRECT

很多臭虫都会集中在边界附近，所以应该多注意。

一致性(Conformance)——值是否符合预期的格式？

很多时候，传递给方法的值或者方法运行后产生的值必须符合某种特定的格式。必须考虑的是，如果数据不能像期望的那样符合格式要求，将会出现什么情况。

有序性(Ordering)——一组值是该有序的，还是该无序的？

应该考虑数据顺序，或者是在一个很大的数据集合中某一数据的位置。

区间性(Range)——值是否在一个合理的最大值和最小值的范围之内？

对于一个变量，它所属类型的取值范围可能比需要的或想要的更加宽广。比如，人的年龄、角度等。

引用、耦合性(Reference)——代码是否引用了一些不受代码本身直接控制的外部因素？

如果对于类的状态、其它对象的状态，或者全局应用程序的状态，需要作一些假设，那么就需要对代码进行测试，保证其在假设未满足的情况下运行良好。前置条件和后置条件都必须检测。

前置条件（preconditions）：系统必须处于什么状态下，该方法才能运行。当前置条件不能满足的情况下程序是否能够正确运行。

后置条件（postconditions）：方法运行之后将会有哪些状态发生。程序的返回结构必须检查，伴随产生的副作用也必须检查。

存在性(Existence)——值是否存在（要小心null、0、“”、有时可能还需要注意空格字符串）？

存在性的问题很容易出现在方法的参数上，也经常出现在方法要用到的类的属性上。特别是引用类型，要特别注意。当遇到null等值时，采取什么策略需要及早考虑。应该形成一贯的处理策略，形成风格。可以考虑抛出异常，并且Message描述问题应尽量细致明确。

基数性(Cardinality)——是否恰好有足够的值？

对基数性问题的认识我目前还不是很透彻。

时间性，绝对的或者相当的(Time)——所有事情是否都是按顺序发生的？是否在正确的时间？是否及时？

测试边界是最有价值的工作，因为bug通常会集中在这里。边界测试需要考虑的主要问题：

完全伪造或者不一致的输入数据。

格式错误的数据。

空值或者不完整的值，如0， 0.0， “”， null之类的。

一些与意料中的合理值相去甚远的数值。

如果是传入一系列数据，要考虑是否允许重复，考虑值是否应该有特定顺序，顺序是否可能有错误等。

检查反向关联

对于一些方法，我们可以使用反向的逻辑关系来验证它们。要注意的是，当你同时编写了原方法和它的方向测试时，一些bug可能会被在两个函数中都出现的错误所掩盖。在可能的情况下，应该使用不同的原理来编写反向测试。

使用其他手段来实现交叉检查

通常解决一个问题会有多种手段，如果你选择了其中一个方法，那么就可以用其它的方法来检验它。另一种方法就是：使用类本身不同组成部分的数据，并且确信它们能“合起来”。

强制产生错误条件

应当能够通过强制引发错误，来测试你的代码是如何处理所有这些真实世界中的问题的。

下面是一些我们能想到的环境方面的因素：

内存耗光

磁盘用满

时钟出问题

网络不可用或者有问题

系统过载

受限的调色板

显示分辨率过高或者过低

性能特性

一个检查起来会很有益处的部分是性能特性，而不是性能本身。