用于单元测试的NUnit vs. Visual Studio 2008测试项目

我将在工作中开始一个新项目，并想进入单元测试。我们将使用Visual Studio 2008, c#和ASP。NET MVC之类的东西。我正在考虑使用NUnit或Visual Studio 2008的内置测试项目，但我也愿意研究其他建议。是一种系统比另一种更好，还是比另一种更容易使用/理解?

我希望把这个项目设置为“最佳实践”。为我们未来的发展努力。

57011 次浏览
小开

我已经使用NUnit两年了。一切都很好，但是我不得不说Visual Studio中的单元测试系统非常好，因为它在GUI中，可以更容易地对私有函数进行测试，而不必搞得乱七八糟。

此外，Visual Studio的单元测试允许你做覆盖和其他NUnit单独不能做的事情。

小开

Daok命名了Visual Studio 2008测试项目的所有pro。下面是NUnit的优点。

  • NUnit有一个mock框架。
    • NUnit可以在外部运行 IDE。如果你想的话，这很有用 在非微软构建服务器上运行测试， 李CruiseControl。网。< / >
  • NUnit有更多版本即将推出 而不是visual studio。你没有 为了新版本等了好几年。 而且您不必安装新版本的IDE
    • 正在开发扩展 对于NUnit，如行测试等
  • Visual Studio测试需要很长时间 因为某种原因开始。这是 在Visual Studio 2008中更好， 但还是太慢了 以我的口味。快速运行测试 看看你有没有弄坏什么东西 可能要花很长时间。NUnit和 类似于测试驱动。网络运行 从IDE测试实际上是很多的 得更快。尤其是跑步的时候 单独的测试。 Kjetil Klaussen认为，这是由Visual Studio测试器引起的。在TestDriven中运行MSTest测试。Net使MSTest的性能与NUnit相当
小开

单元测试框架实际上并不重要，因为你可以用单独的项目文件和条件编译转换测试类(就像这样，Visual Studio→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插件很好，不是很贵…对于普通的Visual Studio 2008，你必须从你的测试类或测试列表中找到测试。使用TestDriven。网，你可以直接从你正在测试的类中运行测试。毕竟，单元测试应该易于维护，并且离开发人员很近。

小开

xUnit是另一种可能的绿地项目。它的语法可能更直观，但它与其他框架并不兼容。

小开

首先我想纠正一个错误的说法:你可以使用命令行在Visual Studio之外运行MSTest。尽管一些CI工具，如TeamCity，对NUnit有更好的支持(可能会随着MSTest变得更流行而改变)。

在我目前的项目中，我们两者都使用，唯一的大区别是，我们发现MSTest总是作为32位运行，而NUnit运行为32位或64位测试，这只在你的代码使用32/64位依赖的本机代码时才重要。

小开

据我所知，目前。net有四个可用的单元测试框架:

NUnit一直处于领先地位，但在过去一年左右，这种差距已经缩小。我自己还是更喜欢NUnit，特别是他们不久前添加了一个流畅的界面，这使得测试非常易读。

如果您刚刚开始进行单元测试，这可能没有太大区别。一旦你跟上了进度，你就能更好地判断哪个框架最适合你的需求。

小开

Visual Studio测试框架的一个小麻烦是，它会创建许多测试运行文件，这些文件往往会使您的项目目录变得混乱——尽管这并不是什么大问题。

此外，如果你缺少诸如TestDriven。网这样的插件，你就不能在Visual Studio环境中调试你的NUnit(或MbUnit、xUnit等)单元测试，就像你可以在Microsoft Visual Studio测试框架中那样，它是内置的。

小开

Visual Studio 2008内置单元测试框架的优点/变化:

  1. 2008版现已在 专业版(在此之前 需要昂贵的Visual Studio版本，以及 这只是开发者单元 测试)留下了很多 开发者唯一的选择是
    2. .打开/外部测试框架
  2. 由单个公司支持的内置API。
  3. 使用相同的工具来运行和创建测试(你也可以使用命令行MSTest运行它们)。
  4. 简单的设计(假定没有模拟框架，但这对许多程序员来说是一个很好的起点)。
  5. 给予长期支持(我仍然记得NDoc发生了什么，我不想承诺一个可能在五年内不被支持的测试框架，但我仍然认为NUnit是一个伟大的框架)。
  6. 如果使用Team Foundation Server作为后端，您可以用失败的测试数据以一种简单的方式创建工作项或错误。
小开

有点偏离主题，但如果你使用NUnit，我可以推荐使用ReSharper——它为Visual Studio UI添加了一些按钮，使它更容易在IDE中运行和调试测试。

这篇评论略显过时，但更详细地解释了这一点:

使用ReSharper作为TDD工具包的重要组成部分

小开

MSTest本质上是略微重做的NUnit，增加了一些新特性(比如程序集设置和拆卸，而不仅仅是fixture和测试级别)，并且缺少了一些最好的部分(比如新的2.4约束语法)。NUnit更成熟，其他厂商对它的支持也更多;当然，因为它一直是免费的(而MSTest只进入了Visual Studio 2008的专业版，在此之前它的sku要贵得多)，而且大多数ALT.NET项目都使用它。

话虽如此，还是有一些公司非常不愿意使用没有微软标签的东西，尤其是OSS代码。因此，拥有官方的微软测试框架可能是这些公司需要进行测试的动机;老实说，重要的是测试，而不是你使用什么工具(并且使用Tuomas Hietanen的代码，你几乎可以让你的测试框架可互换)。

小开

我得到消息，“NUnit文件结构比vstest更丰富”… 当然，如果你更喜欢NUnit的文件结构，你可以用另一种方式来使用这个解决方案，像这样(NUnit→Visual Studio):

 #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

或任何其他转换…:-)这里的用法只是编译器的别名。

小开

与NUnit相比，我对Visual Studio单元测试的主要不满是Visual Studio测试创建倾向于为私有成员访问注入一堆生成的代码。

有些人可能想测试他们的私有方法，有些人可能不想。那是另一个话题了。

我担心的是，当我编写单元测试时，它们应该被严格控制，这样我才能确切地知道我在测试什么以及我如何测试它。如果有自动生成的代码，我就失去了一些所有权。

小开

我更喜欢使用MS的小测试框架，但现在我坚持使用NUnit。多发性硬化的问题通常是(对我来说)

  • 共享“tests"文件(无意义)，必须是维护
  • 测试列表会与多个开发人员/ vcs产生冲突
  • 糟糕的集成UI -令人困惑的设置，繁重的测试选择
  • 没有好的外部流道

警告

  • 如果我正在测试一个aspx站点，我会肯定使用MS的
  • 如果我是独自开发，MS也可以
  • 如果我的技能有限，不能配置NUnit:)

我发现编写我的测试并启动NUnitGUI或其他前端(testDriven的价格非常非常非常昂贵)要容易得多。使用命令行版本设置调试也非常简单。

小开

我从MSTest开始，但我因为一个简单的原因而改变了。MSTest不支持来自其他程序集的测试方法的继承。

我讨厌多次编写相同的测试。特别是在一个大型项目中，测试方法可以很容易地运行到100个测试。

NUnit正是我所需要的。NUnit唯一缺少的是Visual Studio插件，它可以显示每个测试的红色/绿色状态(如虚拟班级)。

小开

我已经使用两者做了一些TDD，(也许我有点笨)NUnit似乎对我来说使用起来更快更简单。我说的很多，就是很多。

在MSTest中，到处都有太多的属性——真正进行测试的代码就是你可能在这里或那里读到的那些小行。一片混乱。在NUnit中，执行测试的代码只是控制属性，就像它应该做的那样。

同样，在NUnit中，你只需要点击你想要运行的测试(只有一个?一个班的所有测试?一个装配?解决方案?)一个点击。窗户又大又亮。你可以看到清晰的绿灯和红灯。你真了解一眼就能看到什么。

在VSTS中，测试列表卡在屏幕的底部，它又小又丑。你得仔细看看才能知道发生了什么事。而且您不能只运行一个测试(好吧，我还没有发现!)。

当然，我可能是错的——我刚刚读了21篇关于“如何使用vst&s做简单的TDD”的博客文章。我应该多读些书;你说得对。

在《NUnit》中，我读了一本。同一天我也去了tdd。与乐趣。

顺便说一下，我通常很喜欢微软的产品。Visual Studio确实是开发人员能买到的最好的工具——但是Visual Studio Team System中的TDD和工作项管理真的很糟糕。

小开

如果你正在考虑MSTest或NUnit，那么我建议你看看运行工具。我的理由是

  1. TestDriven。净的兼容性。没有什么比将TestDriven.Net.ReRunWithDebugger绑定到键盘组合更好的了。
  2. Gallio框架。Gallio是一个像NUnit一样的测试者。唯一的区别是它不关心你是用NUnit、MSTest、xUnit还是MbUnit写测试。他们都跑了。
  3. 与NUnit的兼容性。NUnit中的所有特性都被MbUnit支持。我认为你甚至不需要改变你的属性(将不得不检查)，只需要你的引用和usings。
  4. 收集断言。MbUnit有更多的Assert案例，包括CollectionAssert类。基本上，您不再需要编写自己的测试来检查两个集合是否相同。
  5. 组合测试。如果您可以提供两组数据并对所有数据组合进行测试，这不是很酷吗?单位为MbUnit。

我最初选择MbUnit是因为它的[RowTest ....我找不到一个回去的理由。我把我所有的活动测试套件从NUnit移过来，再也没有回头。从那时起，我已经将两个不同的开发团队转换为收益。

小开

我不喜欢Visual Studio的内置测试框架，因为它迫使你创建一个单独的项目，而不是把你的测试作为你正在测试的项目的一部分。

小开

随着。net 4.0中代码合约制度的发布和静态检查器的可用性，理论上你需要编写更少的测试用例，而像Pex这样的工具将有助于识别这些用例。将这一点与前面的讨论联系起来，如果您需要更少地使用单元测试，因为您的契约会覆盖您的尾部，那么为什么不直接使用内置组件呢，因为这样可以少管理一个依赖项。这些天来，我只追求简单。: -)

参见:


提交答案