单元测试-使用nmock测试你的.NET代码(2)

理解单元测试中的困难

在进行我为这篇文章所写的例子代码的旅程之前,有必要理解一下下面的难题:要进行单元测试的库有一个复杂的依赖集合。尽管最好是设计出具有最小限度的依赖集合的库,但有时候这是不切实际的,特别是当库在设计的时候就没考虑到可测性。当要进行单元测试的库具有一个复杂的依赖集合的时候,这些依赖项可能需要困难的或费时的、并有可能给测试过程带来麻烦的初始过程。考虑一个使用了需要与数据库服务器通信的数据访问组件的商业逻辑库,如下面的图示1。

尽管商业逻辑库和数据访问组件之间是基于接口绑定的,但是商业逻辑库在单元测试中仍然需要访问数据访问组件所提供的属性和方法,在这当中就存在着困难。

数据访问组件需要一个与数据库的连接来工作。这就意味着你需要配置组件来连接上正确的数据库并且你几乎肯定需要建立一个数据库的测试实例,所以你不得不冒着在测试中破坏产品数据库的危险。如果你使用SQL Server 2000,这还可能是一个可控制的任务,但是如果数据访问组件提供的是一个基于大型机数据库访问呢?在后面一种情况下,建立数据库的测试实例很大程度上是不切实际的。即使是使用SQL Server,时间也可能是一个抑制测试进行的因素。

然而,在这种情况下,配置测试的数据访问层并不是唯一的困难。如果你的数据访问组件是你所开发的工程中的一部分,它可能甚至还不存在,并且即使它存在,它仍然非常可能处于具有许多已知的或未知的bug的开发过程中。在这种情况下,你还是冒着即使测试代码没有缺陷但由于数据访问层中可能出现的bugs而导致单元测试不通过的风险。也就是说,在这样的情况下,所要测试的库并不能从其他模块中彻底独立出来,因此在这点上测试也就不再是单元测试了。

你可能感兴趣的:(单元测试-使用nmock测试你的.NET代码(2))