跟小D每日学口语

掌握单元测试工具Nunit教程

测试代码必须做以下几件事情:
  准备测试所需的条件
  调用要测试的方法
  验证被测方法的行为和期望的行为是否一致
  完成后清理各种资源
  为了使用NUnit框架,需要做这些工作
  1.使用using声明引用必要的NUnit类(并添加一个指向NUnitDll的引用)
  2.定义一个测试类,必须是Public的、包换一个public的没有参数的构造函数,并且在类定义上加上[TestFixture]attribute标记
  3.在测试类中包含用[Test]attribute标记的方法。

特性
  在使用NUnit框架时,除了上面提到的[TestFixture]和[Test]特性外,还有一些有用的特性。灵活使用这些特性,将有助于提高测试代码开发的效率。
 1. Per-method的Setup和Teardown
  [Setup]:用此Attribute指定的方法用于环境的建立,NUnit在调用每个[Test]方法之前,将调用此特性标记的方法
  [Teardown]:和[Setup]一样,只是调用的时机是在每个[Test]方法完成后,用于环境的清理。
 2. Per-class Setup和Per-class Teardown
  [TestFixtureSetup]以及[TestFixtureTearDown]特性和上述的[Setup]以及[Teardown]类似,只是其作用于整个[TestFixture]类而已。可以使用这两个特性标记的方法对整个test class设置和清理环境。
 3. 使用Categories分类
  [Category(“分类名”)]用于指定某个测试方法所属的“类型”。用此特性将各个测试方法分类后,可以在NUnit环境中指定需要执行的类型。
  可以将此特性写在[Test]特性一起,如:
  [Test, Category(“test_0001”)]
 也可以分开两行:
  [Test]
  [Category(“test_0001”)]
 Category还有一个Explicit属性,可以显式排除该Category的运行(除非在NUnit GUI中指定),写法如下:
  [Category(“test_0001”, Explicit=true)]

 4.测试预期的异常:ExpectedException
  对测试而言有两种异常:从测试代码抛出的异常;由于某个模块错误而引发的异常.
  第二种异常会在NUnit中捕获并作测试失败处理。而有时我们需要测试被测试方法是否抛出了期望的异常(例如,特意传入的错误参数),就可以用以下方法。
  [ExpectedException(typeof(SomeException))]或:[Test,ExpectedException(typeof(SomeException))]
  注意,一旦期望的异常抛出了,剩余的代码就会被跳过。
 5.临时忽略一些测试:Ignore
  当你写了一些测试代码,但并不打算马上执行时,可以使用Ignore特性。
 [Test,Ignore(“message”)]
  这个测试将被跳过,并且在NUnit GUI中给出黄色的状态栏。

技巧
  有六个值得测试的具体部位,它们能够提高你的测试水平。这六个方面可以统称为Right_BICEP:
  Right : 结果是否正确(Right)
  对于测试而言,首要的也是最明显的任务就是查看所期望的结果是否正确-验证结果。
  这里的结果是指确认代码所做的和你的期望是一致的。
        B    : 边界(boundary)条件是否正确
                边界条件包括许多内容,将在下一节(2.3.边界条件)中集中描述。
        I    : 是否可以检查反向(inverse)关联
  对一些方法,可以用反向的逻辑关系来验证它们。例如,为了检查某条记录是否成功的插入了数据库,可以通过查询这条记录来验证,等等。
  值得注意的是,当同时编写原方法和它的反向测试时,一些BUG可能会被两者中都有的错误所掩饰。在可能的情况下,应该用不同的原理来实现反向测试。
        C    : 是否可以使用其它方法来跨检查(cross-check)结果
        E    : 错误条件(error condition)是否可以重现
  应该能够通过强制引发真实世界中的错误-网络断开、程序崩溃等-来测试代码如何处理这些问题。简单的无效参数之类的错误会很简单,但要模拟复杂的错误就需要一些特殊的技术。在下面的文字中,将讨论使用Mock技术来解决如何强制产生错误的问题。
        P    : 性能(performance)方面是否满足条件
  这里的性能特征并不是指程序的性能本身,而是指性能的那种“随着规模增大,问题越来越复杂”的趋势。我们应该使用一个性能特性的快速回归测试,避免出现某些修改使得程序变得很慢却无法对其进行定位的情况。

posted @ 2009-11-25 15:05  简简单单幸福  阅读(2236)  评论(0编辑  收藏  举报