学习NUnit测试3（比较详细的NUnit2.0使用说明[转]）

[align=center]NUnit2.0详细使用方法 [/align]
注：NUnit中文文档可以参看我的另一个站点:http://www.36sign.com/nunit

前一段时间,有人问我在.NET里如何进行TDD开发.这个问题促使我想对NUnit做一个详细的介绍.因为我们大家都知道NUnit是在.NET进行TDD的利器.
如果你已经知道很多关于NUnit的应用,请指出我的不对之处和提出一些建议，使本文更加完善.如果你对NUnit还不是很了解的话,我建议你还是阅读一下.
本文分为以下部分:

1. TDD的简介

首先什么是TDD呢?Kent Beck在他的<<测试驱动开发 >>(Addison-Wesley
Professional,2003)一书中,使用下面2个原则来定义TDD:
·除非你有一个失败的自动测试,永远不要写一单行代码.
·阻止重复
我想第一个原则是显而易见的.在没有失败的自动测试下就不要写代码.因为测试是嵌入在代码必须满足的需求中.如果没有需求,就没有必要实现任何东西.所以这个原则阻止我们去实现那些没有测试和在解决方案中不需要的功能.

第二个原则说明了在一个程序中,不应该包含重复的代码.如果代码重复,我想这就是不好的软件设计的象征.随着时间的流逝,它会对程序造成不一致的问题,并且使代码变非常混乱
,因为我们时常不会记得重复代码的位置.如果发现代码重复,我想我们应该立即删除代码重复.其实这就涉及到重构了.在这里我就不多讲了.
一般来说,测试分为2种类型,一是程序员自己的测试,另外一种是客户的测试.关于客户测试，我推荐一个FIT的框架，非常不错。在这里，我们讲的TDD就是程序员测试.那么什么是程序员测试呢?我认为就是我们常说的单元测试.既然是单元测试,在.NET里势必会用到某些工具,目前最著名恐怕就是我即将介绍的NUnit了,

2.NUnit的介绍

NUnit是一个单元测试框架,专门针对于.NET来写的.其实在前面有JUnit(Java),CPPUnit(C++),他们都是xUnit的一员.最初,它是从JUnit而来.现在的版本是2.2.接下来我所用的都是基于这个版本.
NUnit最初是由James W. Newkirk, Alexei A. Vorontsov 和Philip A. Craig,
后来开发团队逐渐庞大起来.在开发过程中, Kent Beck 和Erich
Gamma2位牛人也提供了许多帮助.看来对于NUnit还真是下了一番力气了.J
NUnit是xUnit家族种的第4个主打产品,完全由C#语言来编写,并且编写时充分利用了许多.NET的特性,比如反射,客户属性等等.
最重要的一点是它适合于所有.NET语言.
如果你还没有下载,可以到http://www.nunit.org/去下载.

2.1 NUnit的介绍

Ok,下面正式讲解NUnit.在讲解之前,看看几张图片:
using System;
2 using NUnit.Framework;
3 namespace MyTest.Tests
4

[/code]

TestAttribute

Test属性用来标记一个类(已经标记为TestFixture)的某个方法是可以测试的.为了和先前的版本向后兼容,头4个字符(“test”)忽略大小写.(参看http://nunit.org/test.html)

这个测试方法可以定义为:

public void MethodName()

从上面可以看出,这个方法没有任何参数,其实测试方法必须没有参数.如果我们定义方法不对的话,这个方法不会出现在测试方法列表中.也就是说在NUnit的界面左边的工作域内,看不到这个方法.还有一点就是这个方法不返回任何参数,并且必须为Public.

例如:

1using System;
2using NUnit.Framework;
3
4namespace MyTest.Tests
5

一般来说,有了上面两个属性,你可以做基本的事情了.

另外，我们再对如何进行比较做一个描述。
在NUnit中，用Assert（断言）进行比较，Assert是一个类，它包括以下方法：AreEqual，AreSame，Equals， Fail，Ignore，IsFalse，IsNotNull，具体请参看NUnit的文档。

3.如何在.NET中应用NUnit

我将举个例子,一步一步演示如何去使用NUnit.

第1步.为测试代码创建一个Visual Studio工程。

在Microsoft Visual Studio .NET中，让我们开始创建一个新的工程。选择Visual C#工程作为工程类型，Class
Library作为模板。将工程命名为NUnitQuickStart.图4-1是一个描述本步骤的Visual Studio .NET。

using System;
2using NUnit.Framework;
3
4namespace NUnitQuickStart
5

第4步.建立你的Visual Studio 工程，使用NUnit-Gui测试

从程序->NUnit2.2打开NUnit-gui,加载本本工程编译的程序集.
为了在Visual Studio .NET中自动运行NUnit-Gui，你需要建立NUnit-Gui作为你的启动程序：
在 Solution Explorer里右击你的NunitQuickStart工程。
在弹出菜单中选择属性。
在显示的对话框的左面，点击Configuration Properties夹
选择出现在Configuration Properties夹下的Debugging。
在属性框右边的Start Action部分，选择下拉框的Program作为Debug Mode值。
按Apply按钮
设置NUnit-gui.exe作为Start Application。，你既可以键入nunit-gui.exe的全路径，也可使用浏览按钮来指向它。

图4-3 帮助描述本步骤:
using System;
2using NUnit.Framework;
3
4namespace NUnitQuickStart
5

我们仔细一看,不对,有重复的代码,如何去除重复的代码呢?我们可以提取这些代码到一个独立的方法,然后标志这个方法为SetUp
属性,这样2个测试方法可以共享对操作数的初始化了,这里是改动后的代码:

1using System;
2using NUnit.Framework;
3
4namespace NUnitQuickStart
5

这样NUnit将在执行每个测试前执行标记SetUp属性的方法.在本例中就是执行InitializeOperands()方法.记住，这里这个方法必须为public，不然就会有以下错误：Invalid Setup or TearDown method signature

ExpectedException

这里是一个验证这个假设的测试.有的时候,我们知道某些操作会有异常出现,例如,
在实例中增加除法,某个操作被0除,抛出的异常和.NET文档描述的一样.参看以下源代码.

[Test]
[ExpectedException(typeof(DivideByZeroException))]
public void DivideByZero()

除了[Test]属性之外, DivideByZero方法有另外一个客户属性:
ExpectedException.在这个属性里,你可以在执行过程中捕获你期望的异常类型,例如在本例就是DivideByZeroException.如果这个方法在没有抛出期望异常的情况下完成了,这个测试失败.使用这个属性帮助我们写程序员测试验证边界条件(Boundary
Conditions).

Ignore 属性

由于种种原因,有一些测试我们不想运行.当然,这些原因可能包括你认为这个测试还没有完成,这个测试正在重构之中,这个测试的需求不是太明确.但你有不想破坏测试,不然进度条可是红色的哟.怎么办?使用Ignore属性.你可以保持测试,但又不运行它们.让我们标记MultiplyTwoNumbers测试方法为Ignore属性:

[Test]
[Ignore("Multiplication is ignored")]
public void MultiplyTwoNumbers()
using NUnit.Framework;
2
3[TestFixture]
4public class DatabaseFixture
5

Test Suite

Test Suite是test case或其他test suite的集合.
合成(Composite),模式描述了test case和test suite之间的关系.
参考来自NUnit的关于Suite的代码
Suite Attribute

1namespace NUnit.Tests
2

Category属性

对于测试来说，你有的时候需要将之分类，此属性正好就是用来解决这个问题的。
你可以选择你需要运行的测试类目录，也可以选择除了这些目录之外的测试都可以运行。在命令行环境里 /include
和/exclude来实现。在GUI环境下，就更简单了，选择左边工作域里的Catagories Tab，选择Add和Remove既可以了。
在上面的例子上做了一些改善，代码如下：

1using System;
2using NUnit.Framework;
3
4namespace NUnitQuickStart
5
2                        [Test,Explicit]
3                        [Category("Exception")]
4                        [ExpectedException(typeof(DivideByZeroException))]
5                        public void DivideByZero()
6

为什么会设计成这样呢？原因是Ingore属性忽略了某个test或test
fixture，那么他们你再想调用执行是不可能的。那么万一有一天我想调用被忽略的test或test
fixture怎么办，就用Explicit属性了。我想这就是其中的原因吧。
Expected Exception属性 
期望在运行时抛出一个期望的异常，如果是，则测试通过，否则不通过。
参看下面的例子：

1[Test]
2[ExpectedException(typeofInvalidOperationException))]
3public void ExpectAnException()
4

在本测试中，应该抛出DivideByZeroException，但是期望的是InvalidOperationException，所以不能通过。如果我们将[ExpectedException(typeof(InvalidOperationException))]改为[ExpectedException(typeof(DivideByZeroException))]，本测试通过。

5 . 测试生命周期合约 
如果记得test
case的定义,其中一个属性是测试的独立性或隔离性.SetUp/TearDown方法提供达到测试隔离性的目的.SetUp确保共享的资源在每个测试运行前正确初始化,TearDown确保没有运行测试产生的遗留副作用.
TestFixtureSetUp/TestFixtureTearDown同样提供相同的目的,但是却在test
fixture范围里,我们刚才描述的内容组成了测试框架的运行时容器(test runner)和你写的测试之间的生命周期合约(life-cycle
contract).
为了描述这个合约,我们写一个简单的测试来说明什么方法调用了,怎么合适调用的.这里是代码:
[code]

1using System;
2using NUnit.Framework;
3[TestFixture]
4public class LifeCycleContractFixture
5

当编译和运行这个测试,可以在System.Console窗口看到下面的输出:

FixtureSetUp
SetUp
Test 1
TearDown
SetUp
Test 2
TearDown
FixtureTearDown

可以看到, SetUp/TearDown方法调用在每个测试方法的前后.
整个fixture调用一次TestFixtureSetUp/TestFixtureTearDown方法.

目前应该可以简单的应用NUnit2.0了