.NET单元测试（二）

三 单元测试的标准

虽然要进行单元测试的代码会是各种各样的，但是编写单元测试代码还是有规律可循的。测试的对象一般情况下分为方法（包含构造函数）、属性，因此我们按照这两个方向来确定单元测试的标准。

由于现在大多数开发人员还没有真正使用过 .NET的单元测试工具，对于单元测试的了解程度也不高。因此我们这里也不便于制定非常多的标准。我们当前主要针对两大方面进行规范：

l 哪些代码需要添加单元测试？

l 单元测试代码的写法？

3.1 哪些代码需要添加单元测试

如果项目正处在一个最后冲刺阶段，主要的编码工作已经基本完成。因此要全面的添加单元测试，其实是比较大的投入。所以单元测试不能一次性的全部加上，我们只能通过一步一步的来进行测试。

第一步，应该对所有程序集中的公开类以及公开类里面的公开方法添加单元测试。

第二步，对于构造函数和公共属性进行单元测试。

第三步，添加全面单元测试。

在产品全面提交之前可以先完成第一步的工作，二三步可以待其他所有功能完成之后再进行添加。由于第二三步的添加工作其实于第一步类似，只是在量上的累加，因此我们先着重讨论第一步的情况。

在作第一步单元测试添加的时候，也需要有选择性的进行，我们要抓住重点进行测试。首先应该针对属于框架技术中的代码添加单元测试。这里就包含操作数据库的组件、操作外部 WebService的组件、邮件接收发送组件、后台服务与前提程序之间的消息传递的组件等等。通过为这些主要的可复用代码进行测试，可以大大加强底层操作的正确性和健壮性。

其次为业务逻辑层对界面公开的方法添加单元测试。这样可以让业务逻辑保持正确，并且能够将大部分的业务操作都归纳到单元测试中，保证以后产品发布之后，一旦出现问题可以直接通过业务逻辑的单元测试来找到 BUG。

剩下的代码大部分属于代码生成器生成的，而且大多数的操作都是类似的，因此我们可以先针对某一个业务逻辑对象做详细的单元测试。通过这样的规定，单元测试添加的范围就减少了很多。

如果项目是刚刚开始的，那么应当对所有公开的方法和属性都添加单元测试。

3.2 单元测试代码的写法

在编写单元测试代码的时候需要认真的考虑以下几个方面：

l 所测试的方法的代码覆盖率必须达到 100％。

l 所测试的代码内部的状态，例如执行了某个方法之后，该方法所在的类中某个属性或者返回值是否与预期相同。

l 被测试代码所使用的外部设备的状态，如数据库是否可读、网络是否可用、打印机是否可用、 WebService是否可用等等。

每一段单元测试代码，必须考虑到以上的三个问题，并且对于这些问题都要有相应的测试。

3.2.1  代码覆盖率要求

在2.5小节中已经讲了什么是代码覆盖率和代码覆盖率查看的方法。在这里我们着重来讲怎样将代码覆盖率提升到100％。

一般情况下，代码覆盖率低，说明测试代码中没有过多的考虑某些特殊情况。特殊情况包括：

l 边界条件数据，比如值类型数据的最大值、最小值、DBNull，或者是方法中所使用的条件边界，例如a>100那么100就变成了这个数据的边界。而且在测试的时候还必须把超出边界的数据作为测试条件进行测试。

l 空数据，一般空数据对应于引用类型的数据，也就是Null值。

l 格式不正确数据，对于引用类型的数据或者结构对象，类型虽然正确但是其内部的数据结构不正确的数据。例如一个数据库实体对象，数据库中要求其某个属性必须为非空，但是这时我们可以属于一个空。这样这个对象就属于一个不正确数据库。

这三种数据都是针对被测试方法中所使用的外部数据来说的。方法中使用的外部数据无非就是方法参数传入的数据和方法所在的对象的属性或者字段的数据。因此在编写测试代码的时候就必须将这些使用到的数据设置为上面这几种情况的数据来检测方法执行的情况。这才能保证方法编写是正确的。

在编写单元测试代码的时候先了解到被测试方法可能会使用的外部数据，然后将这些外部数据一次设置为上面规定的这几种情况，然后再执行方法。这样就基本可以达到外部数据所有情况都能够正确测试到了。

通过这种方法编写的单元测试代码覆盖率一般可以超过80％。

 

3.2.2 预期值是否达到

在编写单元测试的时候，不能单纯的追求代码覆盖率。有时候代码覆盖率已经达到了100％，程序也能正常运行，但是可能会出现方法执行完毕之后某些数据并非预期的数值。这时就必须对执行的结果进行断言。在.NET提供的单元测试模块中，可以在单元测试中直接使用一个类的一些静态方法来判断某个值是否达到了预期的情况。这个类是Assert。在这个类中公开了很多判断等效性、判断开关性、判断非空性等一系列方法。这些方法可以让你提前做出预测，一旦程序执行之后，如果这些断言不能通过，就代表代码有错误。

在使用断言的时候，我们要求要达到平均5行测试代码就要有一个断言。

通过添加断言，我们就可以对程序执行过程中数据的正确性做一个检测，保证我们的程序不出现写错数据的情况或者出现错误状态的情况。

3.2.3 外部设备状态更改时测试是否正常通过

当代码覆盖率和预期值都达到了我们的要求之后，整个程序其实就基本达到了质量标准。但是这样还不全面，因为很多程序都要使用到外部的设备或者程序，例如数据库、打印机、网络、串行口、并行口等等。当这些设备发生改变或者不可用的时候，程序就可能出现一些不可预知的错误。因此一个健壮的程序也必须考虑到这些情况，这时通常都是通过将这些设备确定的设置为这些不正常状态来检测程序可能会出现的问题。然后再在测试程序中将这些条件加上。

上面所介绍的只是简单的单元测试的入门级别的要求，当然真正的单元测试还有很多更加复杂的要求和测试技巧。但是对于一个初学者而言，如果能达到上述的要求，那么你的代码的健壮性应该能够满足大部分要求了。只是在比较标准的工业化开发的时候，才需要将单元测试继续深化。如果有时间的话，我会在以后再详细阐述较深层次的单元测试方法。