2.5 代码覆盖率

　　单元测试写的是否合理或者是否达到了要求的一个的标准是整个测试的代码覆盖率。代码覆盖率其实是测试代码所运行到的实际程序路径的覆盖率。在实际程序中可能会有很多的循环、判断等分支路径。一个好的单元测试应该能够将所有可能的路径都将走到，这样可以保证大多数情况都测试过了。

　　VS2005中也提供了查看代码覆盖率的工具。我们可以通过点击菜单中的“测试”??“窗口”??“代码覆盖率结果”来打开代码覆盖率查看的窗口。

　　若要进行代码覆盖率的检查，我们必须进行设置，因为系统默认情况下是不进行代码覆盖率检测的。若要打开某个测试的代码覆盖率测试，我们必须点击菜单中的“测试”??“编辑测试运行配置”??“本地测试运行。。。。。。”来打开一个测试配置窗口。在该窗口左侧的列表中选中“代码覆盖率”会显示代码覆盖率的设置。在这个配置中会显示当前解决方案中可以用来检测代码覆盖率的程序集，我们将需要进行覆盖率检测的程序集选中然后点击“应用”按钮可以了。

　　设置完毕之后，我们可以直接运行单元测试，测试通过后。我们可以打开代码覆盖率结果窗口，在这里我们能够看到这些测试覆盖了多少代码。当我们在这里双击某个类的时候，可以看到VS已经将代码背景改变了颜色。显示为深棕色的代码是没有覆盖到的代码，我们可以通过在单元测试代码中添加代码来想办法覆盖这些代码。这样一个单元测试的全过程完成了。

　　三 单元测试的标准

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

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

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

　　2 单元测试代码的写法？

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

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

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

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

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

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

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

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

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

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