在NUnit中我能做些什么在MSTest中无法做到吗？

Question

在许多不同的论坛中已经以各种形式提出了这个问题,但是,恕我直言,我还没有找到一个真正回答清楚的地方,所以我要重新构思并再次提问.

我在一个基本的微软商店工作.我们使用TFS,我们所有的开发人员都有MSDN订阅,包括VS的Team Suite版本.所以我们可以访问MSTest.

我已经阅读了各种NUnit与MSTest的比较,而开发者社区似乎非常注重选择NUnit.但至少对我们的情况来说,给出的理由似乎并不是压倒性的或令人信服的.(NUnit更频繁更新,NUnit更快,NUnit不需要TFS等)

如果我选择的话,我可以使用NUnit,但是必须保护使用没有正式支持的开源软件.我需要一个相当令人信服的理由这样做.

我基本上必须回答的是为了证明使用NUnit优先于MSTest是这样的:在NUnit中我能做些什么,我在MSTest中无法做同样的努力吗？

Answer 1

• NUnit包含一个[TestCase]属性,允许实现参数化测试.这在MSTest中不是现成的 - 它可以通过可扩展性来完成.
• MsTest的ExpectedException属性有一个错误,即使它错了,预期的消息永远不会被断言 - 测试将通过.
• NUnit附带一个Assert.Throws API,允许在特定的代码行上测试异常,而不是整个方法.MSTest存在类似的功能(由为NUnit执行此操作的人员实现)但不随MSTest一起提供.
• NUnit包含一个开箱即用的流畅版Assert API.MSTest有第三方扩展,但没有MSTest附带.
• NUnit允许抽象类成为测试装置(因此您可以继承测试装置).MsTest允许这样但将抽象类限制为单个程序集.
• NUnit允许非公共类成为测试装置(截至最新版本)
• NUnit是为单元测试的想法而单独创建的.MSTest是为测试而创建的 - 还有一些单元测试.
• NUnit包含PNunit(使用NUnit运行并行测试).MSTest在Visual Studio 2010中添加了此功能,可通过XML进行配置

Answer 2

Roy,您的信息已经过时,特别是与2010年有关;

Nunit包含一个[TestCase]属性,允许实现参数化测试.这在MSTest中不存在

这可以使用2010年的单元测试可扩展性来实现.

MSTest的ExpectedException属性有一个错误,即使它错了,预期的消息永远不会被断言 - 测试将通过.

纠正那还在那里

NUnit有一个Assert.Throws API,允许在特定的代码行上测试异常而不是整个方法(你可以自己轻松实现这个)

Jim在为NUnit做原始实现的同时为MSTest实现了一个版本的Assert.Throws,NUnit已经包含在后续版本中,MSTest还没有,但它仍然可以使用.

NUnit包含一个流畅的Assert API版本(如前所述 - Assert.That ..)

MSTest的第三方实施了其中的一些

NUnit要快得多

看看杰米的评论他已经设法让MSTest跑得更快:-)

NUnit可以在32位和64位运行测试(MSTest仅在32位IIRC中运行它们)

不是在2010年,内置了64位支持.

NUnit允许抽象类成为测试装置(因此您可以继承测试装置).MsTest没有.

这可以工作,但不能跨组件限制其有用性.

NUnit允许非公共类成为测试装置(截至最新版本)

还在那儿

NUnit是为单元测试的想法而单独创建的.MSTest是为测试而创建的 - 还有一些单元测试.

正确,有很多误解,MSTest与Nunit相同,但MSTest是一个通用框架.

NUnit包含PNunit(使用NUnit运行并行测试).MSTest仅在vs 2010中添加此功能

更正有一个XML配置设置,允许控制并行度.

Answer 3

NUnit有一个更丰富的断言API.例如,api特别优雅(流畅,均匀)

Assert.That(Is.Unique, myResults);  // assert: myResults is a collection of unique items

如果您已经看过JUnit 的Hamcrest扩展,您将会认识到这种风格.

它还有越来越多的扩展,例如性能测试和优秀的VS插件.

Answer 4

我可以向您介绍几个关于MSTest挫折的博客:

• MSBuild,NAnt,NUnit,MSTest和挫折
• 使用MSTest == FAIL清理构建服务器

公平地说,这些人正在尝试在非TFS构建服务器上设置MSTest.他们的一些问题不适用于您的情况.

我们主要是Microsoft商店,并使用TFS进行源代码管理.但是,我们使用TeamCity进行持续集成; 我们喜欢它,它与TFS相当完美地集成在一起.我从未使用过MSTest; 我们多年来一直在使用NUnit,并且没有理由改变.

MSTest应该与Team Suite紧密集成,因为Team Suite(因为你的公司已经为此支付了巨额费用)是一个有利于它的点.

NUnit带有较少的供应商锁定,并且具有丰富的API.正如serg10指出的那样,Assert.That语法特别强大和优雅.

最后,你可以编写好的单元测试而不需要所有的花哨功能.其中一些甚至可能妨碍(这是xUnit.net背后的理论).我建议你的团队在一个测试框架上标准化; 避免在MUnest和NUnit中的其他代码中使用一些代码.

我认为编写好的测试比选择框架更重要.考虑阅读单元测试的艺术:使用.NET中的示例,编写一些测试,然后查看MSTest是否足以满足您团队的需求.

编辑:单元测试艺术的附录B对微软的单元测试框架有一些很好的评论.它提到YUnit作为扩展MSTest是多么繁琐的一个例子.但是,由于紧密集成,作者确实为团队系统用户建议了MSTest.

Answer 5

我在MsTest和NUnit之间有一个很好的方式.您可以使用MSTest框架来运行测试(每个测试的TestClass属性和TestMethod属性),但使用NUnit Assert API.

这样做:

using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert;  

现在你可以使用Assert.That(..)并且仍然有TFS自动构建和测试报告.您的测试可以在VS,TestDriven.net或Resharper中运行,无关紧要,测试将失败或正确传递,失败输出将根据NUnit框架.

见这里:http: //alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx