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游戏及实践

 

介绍的这个游戏是自己根据目前带的团队的实际情况来制定的， 在游戏实践过程中，收到了较好的效果，故打算把这个游戏分享出来，一是分享一下实践，而是集思广益，不断完善，更好的利用游戏来锻炼队伍。下面就将游戏规则，游戏制定说明，游戏适用人数，以及实践情况一一分享。

游戏规则：

1. 团队成员自己排好顺序，轮流进行TDD。TDD三个环节中，只进行测试编写和实现两个环节，故意不设置重构环节。每个人每次只进行一个环节。以此类推。如果团队人数为奇数，则每个人每次进行的环节都会和上一次进行的不一样。如果为偶数，则要重新排列一下，保证每个人每次进行的环节和上次不一样。
2. 不管是编写测试，还是实现，时间要求尽量在5分钟内完成。 如果完成了，得5分。如果没有完成，扣掉2分。
3. 如果编写的测试有错误，其他成员发现了，则测试扣2分，发现者加2分。
4. 如果因为测试步子太大导致实现没有完成，则扣掉编写测试的人2分。
5. 如果实现或者编写测试的人，对代码进行了重构，则加2分。

以上就是整个游戏的规则。

规则设置说明：

1. 采用TDD轮流的方式，已经有较多的人实战过或者了解过，再次就不多说明了。
2. 限定时间，一是为了限定步子不能太大了，二是模拟实际工作中，项目进度压力。
3. 故意不要重构的环节是为了检验是否有人会主动重构，这在项目中很重要。同时辅以加分引导重构。
4. 其他的加分和扣分都是为了朝正确的方向引导。
5. 多人进行轮流TDD，是模拟实际工作中，代码集体所有。

游戏适宜人数：

自己认为3-4人较好，人多了，节奏会没有那么快。

简要的实践情况说明：

1. 这个游戏由团队5人进行的，在最开始几轮，每个人都有被扣分。团队协作不好，没有明确的目标，走一步算一步。
2. 在这个过程中，不断有人挖坑，因为时间的关系，只有一个人重构过一次。但势单力薄啊。
3. 团队的利益，和个人的利益相比，还是个人利益优先啊。
4. 在挖坑和被坑过程中，笑料不断。
5. 传说中没法继续做下去的代码出现了。才几轮过后，就这样了， 超乎我的想象。
6. 在没有办法的情况下，在团队中找了一个人停下来进行大的重构，花了一些时间。
7. 在重构后，5个人分析了一下原因，开始在总的目标和详细设计上先达成了一致，然后按照设计的方式一步一步进行。
8. 这之后，进展明显比之前推进的更平顺，也较少出现扣分，就这样一直持续到最后。
9. 在关键实现上，出现了超过时间的情况，这符合实际情况。

回顾：

1. 在团队协作上存在的问题，团队目标，计划和实施等环节的问题都暴露出来了。
2. 代码集体所有，如果有人挖坑，同时也没人维护代码质量，代码腐烂的程度超乎你的想象。
3. 增强了团队的凝聚力，增加了不少的笑料。
4. 采用的技术多样化，相互之间进行了交叉学习。
5. 个人目标和团队目标的权衡，还真是难题啊。

这次游戏取得的效果，还是比较令人满意的。这个游戏本身也是第一次制定出来，第一次实战，还有不完善的地方，期望有兴趣的同仁一起来参与实践和改进。

 

 

分类: TDD

 心情不爽，发篇随笔调整用一下心情~