NUnit单元测试资料汇总
NUnit单元测试资料汇总
从安装到配置
首先到官网http://www.nunit.org/下载如下图的资料，安装NUnit-2.6.1.msi包。
然后挂在VS2010外部工具这个地方来使用，工具—>外部工具—>添加—>标题：Nunit—>命令：安装路径—>确定。
然后打开Nunit，工具—>Nunit。
VS2010 NUnit 整合插件 Visual Nunit 2010下载：
http://visualstudiogallery.msdn.microsoft.com/c8164c71-0836-4471-80ce-633383031099，下载安装完毕就能在 VS2010 的 视图->其它窗体 中看到 Visual Nunit了（或使用快捷键Ctrl + F7），打开该视图，将之拖到合适的位置。打开如下图，会自动加载测试的方法。
使用入门
建立项目如下图（注意项目依赖，程序集引用）：
|
1
2
3
4
5
6
7
8
9
10
11
|
//Number.cs
namespace
BaseClass
{
public
class
Number
{
public
static
int
TestMethod()
{
return
29;
}
}
}
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
//NunitTestClass.cs
namespace
NunitTestClass
{
/// <summary>
/// 初行-博客园 http://zxlovenet.cnblogs.com
/// </summary>
/// 这是一个测试类
[NUnit.Framework.TestFixture]
public
class
NunberTest
{
//测试用的方法
//方法必须是public，返回类型void,无参
[Test]
public
void
GetTestAreEqual()
{
int
test1 = BaseClass.Number.TestMethod();
//验证test1的值必须是29才能通过
Assert.AreEqual(29, test1);
}
[Test]
public
void
GetTestGreater()
{
int
test1 = BaseClass.Number.TestMethod();
//验证test1de值必须大于0才能通过
Assert.Greater(test1, 30);
}
}
}
|
然后F6生成，找到生成文件如下图：
VS2010下，工具—>Nunit，打开后 File—>New Project…，保存到一个位置，然后点Fiel—>Save。添加程序集：Project—>Add Assembly…，找到测试文件如下图：
打开后的效果如图：
点击Run执行测试，效果如下图：
通过上图可以看出，通过测试的会打“√”，无法通过测试的打“×”。
博客园-初行 2014.3.10编辑
让我们更进一步看一下测试运行器窗口的布局。在右边面板的中间，可以看到测试进度条。进度条的颜色反映了测试执行的状态：
l 绿色 描述目前所执行的测试都通过
l 黄色 意味某些测试忽略，但是这里没有失败
l 红色 表示有失败
底部的状态条表示下面的状态：
l 状态.说明了现在运行测试的状态。当所有测试完成时，状态变为Completed.运行测试中，状态是Running: <test-name> (<test-name>是正在运行的测试名称)。
l Test Cases说明加载的程序集中测试案例的总个数。这也是测试树里叶子节点的个数。
l Tests Run 已经完成的测试个数。
l Failures 到目前为止，所有测试中失败的个数.
l Time 显示运行测试时间（以秒计）
File主菜单有以下内容：
l New Project允许你创建一个新工程。工程是一个测试程序集的集合。这种机制让你组织多个测试程序集，并把他们作为一个组对待。
l Open 加载一个新的测试程序集，或一个以前保存的NUnit工程文件。
l Close关闭现在加载的测试程序集或现在加载的NUnit工程。
l Save 保存现在的Nunit工程到一个文件。如果正工作单个程序集，本菜单项允许你创建一个新的NUnit工程，并把它保存在文件里。
l Save As允许你将现有NUnit工程作为一个文件保存。
l Reload 强制重载现有测试程序集或NUnit工程。NUnit-Gui自动监测现加载的测试程序集的变化。
当程序集变化时，测试运行器重新加载测试程序集。（当测试正运行时，现在加载的测试程序集不会重新加载。在测试运行之间测试程序集仅可以重新加载。一个忠告：如果测试程序集依赖另外一个程序集，测试运行器不会观察任何依赖的程序集。对测试运行器来说，强制一个重载使全部依赖的程序集变化可见。
l Recent Files 说明5个最近在NUnit中加载的测试程序集或NUnit工程（这个列表在Windows注册表，由每个用户维护，因此如果你共享你的PC，你仅看到你的测试）。最近程序集的数量可以使用Options菜单项修改，可以访问Tool主菜单。
l Exit退出。
l View菜单有以下内容：
l Expand一层层扩展现在树中所选节点
l Collapse 折叠现在树中选择的节点
l Expand All递归扩展树中所选节点后的所有节点
l Collapse All递归折叠树中所选节点后的所有节点
l Expand Fixtures扩展树中所有代表测试fixture的节点。
l Collapse Fixtures 折叠树中所有代表测试fixture的节点。
l Properties 显示树中现所选节点的属性。
l Tools 菜单由这些项:
l Save Results as XML作为一XML文件保存运行测试的结果。
l Options让你定制NUnit的行为。
l 现在看看右边，你已经熟悉Run按钮和进度条。这里还有一个紧跟Run按钮的Stop按钮：点击这个按钮会终止执行正运行的测试。进度条下面是一个文本窗口，在它上方，由以下4个标签：
l Errors and Failures 窗口显示失败的测试。在我们的例子里，这个窗口是空。
l Tests Not Run 窗口显示没有得到执行的测试。
l Console.Error 窗口显示运行测试产生的错误消息。这些此消息是应用程序代码使用Console.Error输出流可以输出的。
l Console.Out窗口显示运行测试打印到Console.Error输出流的文本消息。
参考资料：http://confach.cnblogs.com/archive/2005/06/20/177817.aspx
总结
NUnit有这样几个优点
1.独立于IDE，可以单独运行。也可以以命令行方式运行。（vs应该也可以吧？）
2.版本更新快。（我不认为这是个优点，而且我也并不觉得快啊。）
3.VS的UT工具运行速度慢。（不一定）
NUite也有这样几个缺点
1.不支持Debug，要安装TestDriven.NET才支持。
2.不支持代码覆盖率的查看，要和NCover一起用。而VS的代码覆盖很清楚。
3.不能自动生成测试代码，也许和CodeSmith一起用好些，不过后着要收费的。
一个小团队TDD游戏及实践
介绍的这个游戏是自己根据目前带的团队的实际情况来制定的， 在游戏实践过程中，收到了较好的效果，故打算把这个游戏分享出来，一是分享一下实践，而是集思广益，不断完善，更好的利用游戏来锻炼队伍。下面就将游戏规则，游戏制定说明，游戏适用人数，以及实践情况一一分享。
游戏规则：
- 团队成员自己排好顺序，轮流进行TDD。TDD三个环节中，只进行测试编写和实现两个环节，故意不设置重构环节。每个人每次只进行一个环节。以此类推。如果团队人数为奇数，则每个人每次进行的环节都会和上一次进行的不一样。如果为偶数，则要重新排列一下，保证每个人每次进行的环节和上次不一样。
- 不管是编写测试，还是实现，时间要求尽量在5分钟内完成。 如果完成了，得5分。如果没有完成，扣掉2分。
- 如果编写的测试有错误，其他成员发现了，则测试扣2分，发现者加2分。
- 如果因为测试步子太大导致实现没有完成，则扣掉编写测试的人2分。
- 如果实现或者编写测试的人，对代码进行了重构，则加2分。
以上就是整个游戏的规则。
规则设置说明：
- 采用TDD轮流的方式，已经有较多的人实战过或者了解过，再次就不多说明了。
- 限定时间，一是为了限定步子不能太大了，二是模拟实际工作中，项目进度压力。
- 故意不要重构的环节是为了检验是否有人会主动重构，这在项目中很重要。同时辅以加分引导重构。
- 其他的加分和扣分都是为了朝正确的方向引导。
- 多人进行轮流TDD，是模拟实际工作中，代码集体所有。
游戏适宜人数：
自己认为3-4人较好，人多了，节奏会没有那么快。
简要的实践情况说明：
- 这个游戏由团队5人进行的，在最开始几轮，每个人都有被扣分。团队协作不好，没有明确的目标，走一步算一步。
- 在这个过程中，不断有人挖坑，因为时间的关系，只有一个人重构过一次。但势单力薄啊。
- 团队的利益，和个人的利益相比，还是个人利益优先啊。
- 在挖坑和被坑过程中，笑料不断。
- 传说中没法继续做下去的代码出现了。才几轮过后，就这样了， 超乎我的想象。
- 在没有办法的情况下，在团队中找了一个人停下来进行大的重构，花了一些时间。
- 在重构后，5个人分析了一下原因，开始在总的目标和详细设计上先达成了一致，然后按照设计的方式一步一步进行。
- 这之后，进展明显比之前推进的更平顺，也较少出现扣分，就这样一直持续到最后。
- 在关键实现上，出现了超过时间的情况，这符合实际情况。
回顾：
- 在团队协作上存在的问题，团队目标，计划和实施等环节的问题都暴露出来了。
- 代码集体所有，如果有人挖坑，同时也没人维护代码质量，代码腐烂的程度超乎你的想象。
- 增强了团队的凝聚力，增加了不少的笑料。
- 采用的技术多样化，相互之间进行了交叉学习。
- 个人目标和团队目标的权衡，还真是难题啊。
这次游戏取得的效果，还是比较令人满意的。这个游戏本身也是第一次制定出来，第一次实战，还有不完善的地方，期望有兴趣的同仁一起来参与实践和改进。
心情不爽，发篇随笔调整用一下心情~