NUnit vs Visual Studio 2008的单元测试测试项目？

我将在工作中启动一个新项目,并希望进入单元测试.我们将使用VS 2008,C#和ASP.NET MVC.我正在考虑使用NUnit或VS2008具有的内置测试项目,但我愿意研究其他建议.一个系统比另一个系统更好,或者比另一个更容易使用/理解？我希望将这个项目设置为我们未来发展努力的"最佳实践".

感谢您的帮助和建议!!

1> Mendelt..：

---

Daok命名了VS2008测试项目的所有专家,这里是NUnit的专业人士.

NUnit有一个模拟框架.

NUnit可以在IDE之外运行,如果你想在像CC.Net这样的非MS构建服务器上运行测试,这可能很有用.

NUnit的版本比visual studio更多.您无需等待多年即可获得新版本并且您无需安装新版本的IDE即可获得新功能.

正在为NUnit开发扩展,例如行测试等.

由于某种原因,Visual Studio测试需要很长时间才能启动.这在2008年更好,但对我的口味来说仍然太慢.快速运行测试,看看你是否没有破坏某些东西可能需要很长时间.使用类似Testdriven.Net的NUnit从IDE运行测试实际上要快得多.特别是在运行单一测试时.
响应Kjetil Klaussen这是由Visual Studio testrunner引起的,在TestDriven.Net中运行MSTest测试使MSTest性能与NUnit相当.

---

你不能只使用mstest.exe在IDE外运行MSTest测试吗？

---

拥有模拟框架的Nunit并没有多大优势.我一直在使用Moq框架的VS 2008单元测试项目,该框架使用了一种新颖的方法,利用LINQ表达式树:http://code.google.com/p/moq/

---

单元测试包含在VS 2008的专业版中.

---

无论如何,对于Nunit来说还有一个优点,就是Resharper有一个非常漂亮的用户界面,它比VS测试组件要快得多.它甚至将失败测试的堆栈跟踪超链接到您的代码.

---

@Jeff Putz:即使在测试项目之外,Resharper也可以运行Visual Studio单元测试.

2> Tuomas Hieta..：

---

单元测试框架实际上并不重要,因为您可以使用单独的项目文件和条件编译(如此,VS-> NUnit)转换测试类:

 #if !NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #else
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

TestDriven.Net插件非常好而且价格不贵......只有普通的VS2008,您必须从测试类或测试列表中找到测试.使用TestDriven.Net,您可以直接从您正在测试的类中运行测试.毕竟,单元测试应该易于维护并且靠近开发人员.

---

我投了这个,因为NUnit比MSTest有更丰富的语法,这意味着你可以从MSTest - > NUnit,但反之亦然,除非你非常小心.历史表明至少有一个人不是.

---

我同意托马斯的观点.假设您使用的是最基本的断言语句,这将起作用,但NUnit约束模型非常强大且足以在MSTest上选择NUnit.

---

@JDPeckham我不是说使用工具应该/不应该做什么的约定并不重要,但是在一天结束时完成工作是最重要的.如果这意味着用钉子的背面砸钉子,因为工具供应商不销售锤子,那么斧头制造商将不得不忍受愤怒.

3> Simara..：

---

VS2008内置单元测试框架的优点/变化

2008版本现在可以在专业版中使用(在它需要昂贵版本的VS之前,这仅适用于开发人员单元测试.)这使得许多开发人员只能选择开放/外部测试框架.

内置API由单个公司支持.

使用相同的工具来运行和创建测试(您可以使用命令行运行它们也是MSTest)

简单的设计(没有授予Mock框架,但对许多程序员来说这是一个很好的起点)

授予长期支持(我还记得nDoc发生的事情,我不想承诺5年内可能不支持的测试框架,但我仍然认为nUnit是一个很棒的框架.)

如果使用团队基础服务器作为后端,则可以以简单的方式创建失败的测试数据的工作项或错误.

---

我认为它仍然在说明微软的测试观点,它不是标准版本,只是专业及以上版本.

4> Patrick Desj..：

---

我已经使用NUnit 2年了.一切都很好,但我不得不说VS中的Unit系统相当不错,因为它位于Gui内部,可以更轻松地测试私有功能,而不必乱用.此外,VS的单元测试允许你做覆盖和NUnit单独做不到的其他事情.

---

你不应该碰你的私处.除了开玩笑之外,有一种想法是,你需要测试的只是你的公共方法.调用所有公共方法应该调用所有私有方法.如果没有通过公共方法调用私有方法,则私有方法是多余的.

---

@Matthew,集成测试正在测试两个或更多单元.测试私有方法只是(巨大的)违反封装的行为,并且可能导致脆弱的单元测试,每次实现更改时都必须对其进行修改.

---

@Lieven:如果你是通过公众测试私有,你实际上是在进行综合测试,而不是单元测试.(当然我不是TDD狂热者,我可能只是测试公众......但我觉得有助于开始战斗)

---

您还可以将[assembly:InternalsVisibleTo(...)]与编译器指令一起使用,以便在进行RTM构建时将其取出.

5> Tarsier..：

---

Visual Studio的测试框架的一个轻微烦恼是,它会创建许多测试运行文件,这些文件往往会混乱您的项目目录 - 尽管这不是什么大不了的事.

此外,如果缺少TestDriven.NET等插件,则无法在Visual Studio环境中调试NUnit(或MbUnit,xUnit等)单元测试,就像使用内置的Microsoft VS测试框架一样.

---

您可以在Visual Studio 2005中调试NUnit测试.

6> Richard Ever..：

---

稍微偏离主题,但如果你使用NUnit我可以推荐使用ReSharper - 它为VS UI添加了一些按钮,使得从IDE中运行和调试测试变得更加容易.

此评论略有过时,但更详细地解释了这一点:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

7> Ben Fulton..：

---

XUnit是绿地项目的另一种可能性.它可能是一种更直观的语法,但与其他框架并不真正兼容.

http://www.codeplex.com/xunit

8> Ian Suttle..：

---

我对NUnit的VS单元测试的主要优点是VS测试创建倾向于为私有成员访问注入一堆生成的代码.

有些人可能想测试他们的私人方法,有些可能不会,这是一个不同的主题.

我担心的是,当我编写单元测试时,他们应该受到极大的控制,所以我确切地知道我正在测试什么以及我正在测试它.如果有自动生成的代码我失去了一些所有权.

9> Sylvain Rodr..：

---

我用两者做了一些TDD(也许我有点笨)nUnit对我来说似乎更快更简单.当我说了很多,我的意思很多.

在MS Test中,到处都有太多的属性 - 进行实际测试的代码是你可以在这里和那里阅读的细线.一团糟.在nUnit中,执行测试的代码就像它应该做的那样支配属性.

另外,在nUnit中,你只需要点击你想要运行的测试(只有一个？所有测试都覆盖了一个类？一个程序集？解决方案？).点击一下.窗户清晰而大.你会得到清晰的绿色和红色灯光.你真的知道在一个视线中会发生什么.

在VSTS中,测试列表卡在屏幕的底部,它很小而且很丑.你必须看两次才能知道发生了什么.你不能只运行一次测试(好吧,我还没发现!).

但我当然可能错了 - 我刚读了大约21篇关于"如何使用VSTS进行简单TDD"的博客文章.我应该读更多,你是对的.

对于nUnit,我读了一个.我当天正在进行TDDing.有趣.

顺便说一句,我通常喜欢微软的产品.Visual Studio确实是开发人员可以购买的最佳工具 - 但Visual Studio Team System中的TDD和工作项管理确实很糟糕.

祝一切顺利.西尔万.

10> Dror Helper..：

---

首先,我想纠正一个错误的陈述:你可以使用命令行在visual studio之外运行msTest.虽然TeamCity等几个CI工具对NUnit有更好的支持(可能会随着msTest变得更受欢迎而改变).在我目前的项目中,我们使用两者,我们发现唯一的大差异是mstest总是以32位运行,而NUnit运行为32位或64位测试,这只有在您的代码使用32/64相关的本机代码时才有意义.

11> Tuomas Hieta..：

---

我得到的消息是"NUnit文件结构比VSTest更丰富"......当然如果你更喜欢NUnit文件结构,你可以使用这个解决方案,就像这样(NUnit-> VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

或者任何其他转换...... :-)这里使用的只是编译器的别名.

12> 小智..：

---

我从MSTest开始,但转换的原因很简单.MSTest不支持从其他程序集继承测试方法.

我讨厌多次编写相同测试的想法.特别是在一个大型项目中,测试方法很容易进入100个测试阶段.

NUnit可以直接满足我的需求.NUnit唯一缺少的是Visual Studio Addin,它可以显示每个测试的红/绿状态(如VSTS).

13> EfForEffort..：

---

.NET测试框架建议和.NET单元测试包？.

---

OT:这里和这里,这两个词的信息量不大.请提供更多描述性文字.

14> AlSki..：

---

如果您正在考虑MSTest或nUnit,那么我建议您查看mbUnit.我的理由是

TestDriven.Net兼容性.没有任何节拍将TestDriven.Net.ReRunWithDebugger绑定到键盘组合.

Gallio框架.Gallio是像nUnits这样的测试跑者.唯一的区别是它不关心你是否在nUnit,msTest,xUnit或mbUnit中编写测试.他们都跑了.

与nUnit的兼容性.mbUnit支持nUnit中的所有功能.我认为你甚至不需要改变你的属性(必须检查它),只需要你的参考和使用.

收集断言.mbUnit有更多的Assert案例,包括CollectionAssert类.基本上,您不再需要编写自己的测试来查看2个集合是否相同.

组合测试.如果您可以提供两组数据并对所有数据组合进行测试,那会不会很酷.它在mbUnit中.

我最初选择了mbUnit因为它的[RowTest ....]功能,我还没有找到回归的理由.我从nUnit移动了所有活动的测试套件,从未回头.从那以后,我将两个不同的开发团队转换成了收益.

15> gilles27..：

---

据我所知,目前有四个框架可供.NET进行单元测试

NUnit的

MbUnit的

MSTest的

的xUnit

NUnit一直在前面,但差距在去年左右已经关闭.我仍然更喜欢NUnit,特别是因为他们在一段时间后添加了一个流畅的界面,这使得测试非常易读.

如果您刚开始进行单元测试,它可能没什么区别.一旦掌握了速度,您就可以更好地判断哪种框架最适合您的需求.

16> 小智..：

---

我不喜欢VS内置测试框架,因为它会强制您创建一个单独的项目,而不是将您的测试作为您正在测试的项目的一部分.

---

实际上,您可以通过手动编辑项目文件并添加用于标识测试项目的ProjectTypeGuids值来欺骗Visual Studio:< ProjectTypeGuids> {3AC096D0-A1C2-E12C-1390-A8335801FDAB}; {FAE04EC0-301F-11D3- BF4B-00C04F79EFBC}</ProjectTypeGuids>

17> David Keaven..：

---

MSTest本质上是NUnit稍微重做的,有一些新功能(例如装配设置和拆卸,不仅仅是夹具和测试级别),并且缺少一些最佳位(例如新的2.4约束语法).NUnit更加成熟,其他供应商对它的支持也更多; 当然,因为它总是免费的(而MSTest只是进入了2008年的专业版,之前它是更昂贵的SKU),大多数ALT.NET项目都使用它.

话虽如此,有些公司非常不愿意使用没有微软标签的东西,尤其是OSS代码.因此,拥有正式的MS测试框架可能是这些公司需要进行测试的动机; 老实说,重要的是测试,而不是你使用的工具(使用上面的Tuomas Hietanen代码,你几乎可以使你的测试框架可以互换).