作者 卢彦
引言：
举一个可能会发生在你身边的事件将更能贴近实际，幸好我们现在就有一件在程序员看来非常普通的任务：
你今天第一天上班，你的项目经理拿给你一叠不算厚的文档，告诉你今天的任务是按照文档中的要求编写一个.Net类，可能因为任务并不复杂，所以他看上去非常的随意。
今天能否很好的完成任务对你来说非常特殊，你拿过来后快速略过了前面大段的项目介绍，因为你知道那些对你并不重要，印象中好象是一个关于售票系统的工程。很快，你找了你需要关注的重点：类的需求说明文档。你详细的看了一遍，感觉并不复杂，类名Ticket,有一个只读的int型公共的属性，名称是Amount，还有两个方法，一个是名称是Sell，功能是将Amount减去一，表示卖掉了一张票，当然，票可不能为负数，如果是的话，抛出一个异常说明原因。另一个是Add，它有一个int型的参数，功能是将这个参数的值加到Amount中去，可能是表示进票之类的事情吧，你不太关心，反正这个程序很简单，你掩饰住内心的狂喜，打开电脑，调出编辑器，开始准备写程序了。
"喂，等等"，项目经理不知道什么时候又转回来了，"我想知道你打算怎么进行单元测试，我最关心的是这个"。
"什么是单元测试？"你转过头一脸沮丧的看着失望的项目经理。
什么是单元测试：
在程序设计过程中会有许多种测试，单元只是其中的一种，单元测试并不能保证程序是完美无缺的，但是在所有的测试中，单元测试是第一个环节，也是最重要的一个环节。单元测试是一种由程序员自行测试的工作。简单点说，单元测试就是测试代码撰写者依据其所设想的方式执行是否产生了预期的结果。关于单元测试的重要性已经有许多文章做了很多深入的分析，这里就不再赘述。
NUnit是一个为Net准备的自动化单元测试框架，它的作用就是帮助你方便的完成单元测试工作，同鼎鼎有名的JUnit一样，都是xUnit家族的成员。它的下载地址是：
http://www.nunit.org
。
测试先行：
"什么？先写测试？"你一定非常惊讶，对！就是先来编写测试代码，按照极限编程（XP）的理论，写测试就是对软件进行设计的过程，它的重要性甚至超过了实际完成功能的代码。先将测试写完，然后再来完成代码，这样，所有的测试通过之日也就是程序完成之时。
首先，我们将NUnit提供的要nunit.framework.dll文件引入到工程中，并创建一个名为TicketTest的类：
[TestFixture]
public class TicketTest
{
[Test]
public void Add()
{
Ticket ticket = new Ticket();
ticket.Add(100);
Assertion.AssertEquals(100, ticket.Amount);
}
}
public class TicketTest
{
[Test]
public void Add()
{
Ticket ticket = new Ticket();
ticket.Add(100);
Assertion.AssertEquals(100, ticket.Amount);
}
}
注意，其中的[TestFixture]和[Test]两个Attribute为NUnit所规定必须要添加的，这样，测试框架就可以知道哪些类或者方法需要进行测试。
我们在Add方法中定义了一个ticket对象，并给他加了100张票，然后就可以使用：
Assertion.AssertEquals(100, ticket.Amount);
来测试ticket的Amount属性是否确实为100。
接下来，我们再向TicketTest中添加一个测试Sell的方法：
[Test]
public void Sell()
{
Ticket ticket = new Ticket();
ticket.Add(100);
ticket.Sell();
ticket.Sell();
ticket.Sell();
Assertion.AssertEquals(97, ticket.Amount);
}
public void Sell()
{
Ticket ticket = new Ticket();
ticket.Add(100);
ticket.Sell();
ticket.Sell();
ticket.Sell();
Assertion.AssertEquals(97, ticket.Amount);
}
这里，我们先加了100张票之后就一口气卖掉了3张，然后看看我们是否还剩下97张票。
好了，这两个方法的测试已经做完了，我们来看一下测试的结果，根据要求，我们写了如下代码：
public
class
Ticket
{
private int amount;
public int Amount
{
get
{
return amount;
}
}
public void Add(int num)
{
}
public void Sell()
{
}
}
{
private int amount;
public int Amount
{
get
{
return amount;
}
}
public void Add(int num)
{
}
public void Sell()
{
}
}
注意这段代码只是为了完成类的结构，方法的实现暂时先空着。然后将这段代码编译成一个dll动态连接库文件：UnitTest.dll。
我们运行NUnit的图形测试工具，打开我们编译好的dll文件，点"Run"按纽，就可以看到如下画面：
很醒目红色，表示测试并没有成功，不过这个是在我们的预料之中的。
接下来，我们向刚才的Ticket类中完成我们的Add方法实现代码：
public void Add(int num)
{
amount += num;
}
保存，重新编译。
切换到NUnit，再点Run，可以看到：
Add方法已经变成绿色了，再接着将Sell方法也完成：
public void Sell()
{
amount -= 1;
}
再来测试，结果就变成：
啊，总算变成美丽的绿色了，大家现在体会到环保的重要性了吧。 ：）
那么可以交任务了吗？等等，别急，还有个异常没测试呢，如果我们的Amount小于0的话，就会产生异常，那么，异常怎么测试呢？请接着看。
测试异常：
还是跟上面一样，先写出测试代码：
[Test]
[ExpectedException( typeof (Exception))]
public void ExcpetionTesting()
{
Ticket ticket = new Ticket();
ticket.Add(3);
ticket.Sell();
ticket.Sell();
ticket.Sell();
ticket.Sell();
}
[ExpectedException( typeof (Exception))]
public void ExcpetionTesting()
{
Ticket ticket = new Ticket();
ticket.Add(3);
ticket.Sell();
ticket.Sell();
ticket.Sell();
ticket.Sell();
}
其中，[ExpectedException(typeof(Exception))]表示我们希望能捕获到发生的异常，如果没有捕获到异常，则表示测试失败。
后面的代码很好理解，我们加了三张票，却卖了四张出去，这可不是炒股，以后没办法平仓的。 ：）
编译运行，我们看到以下的测试画面：
在Ticket类中，我们修改一下Sell方法，让它变成：
public void Sell()
{
if(amount - 1 < 0)
throw new Exception("Amount不能为0");
amount -= 1;
}
编译，再测试，结果如下：
好了，到了这里就算完成我们的单元测试之旅了，大家对如何在C#中进行单元测试一定已经有了一个基本的认识。另外，NUnit并不是只针对C#，事实上，你可以在任何.Net语言中使用NUnit来测试你的单元，方法都一样。
总结：
单元测试看上去虽然有点麻烦，但是它为程序员提供了一个安全的观点，让程序员对自己的程序更加有信心，在减少开发后期进行频繁Debug所耗费时间的同时也为应用软件提供了第一道安全防护网，因此，单元测试是提高开发效率和软件品质的一个重要的手段。
利用UNint，我们可以在.Net编程过程中非常方便的进行单元测试，它图形化的界面和简单而强大的测试框架为我们提供了一个非常舒适而有趣的测试环境，能够让程序员觉得进行单元测试并不枯燥乏味，习惯后甚至还能成为一种乐趣。
看完本文，如果你是引言中那个可怜的程序员的话，你现在就一定能轻松的面对你的项目经理，交上一份令人放心的代码答卷。
原文地址
原文地址