NUnit与Visual Studio 2008的单元测试测试项目？[关闭]

我将要在工作中启动一个新项目，并想进入单元测试。我们将使用VS 2008，C＃和ASP.NET MVC。我正在考虑使用NUnit或VS2008具有的内置测试项目，但是我愿意研究其他建议。一个系统是否比另一个系统好，或者比另一个系统更易于使用/理解？我希望将这个项目设置为“最佳实践”，以进行我们的开发工作。

感谢您的帮助和建议！

Daok命名了VS2008测试项目的所有专家，以下是NUnit的专家。

• NUnit有一个模拟框架。
• NUnit可以在IDE外部运行，如果您想在非MS构建服务器（例如CC.Net）上运行测试，这将非常有用
• NUnit具有比Visual Studio更多的版本。您不必为新版本等待数年，也不必安装新版本的IDE即可获得新功能。
• 正在为NUnit开发扩展，例如行测试等。
• 由于某种原因，Visual Studio测试需要很长时间才能启动。这在2008年比较好，但就我的口味而言仍然太慢了。快速运行测试以查看是否没有破坏某些东西可能会花费太长时间。使用TestDrive.Net之类的NUnit从IDE运行测试实际上要快得多。特别是在运行单个测试时。
  根据Kjetil Klaussen的说法，这是由Visual Studio测试运行程序引起的，在TestDriven.Net中运行MSTest测试可以使MSTest性能与NUnit相当。

单元测试框架实际上并不重要，因为您可以使用单独的项目文件和条件编译（例如VS-> NUnit）转换测试类：

 #if！NUNIT
  使用Microsoft.VisualStudio.TestTools.UnitTesting;
 ＃其他
  使用NUnit.Framework;
  使用TestClass = NUnit.Framework.TestFixtureAttribute;
  使用TestMethod = NUnit.Framework.TestAttribute;
  使用TestInitialize = NUnit.Framework.SetUpAttribute;
  使用TestCleanup = NUnit.Framework.TearDownAttribute;
  使用TestContext = System.String;
  使用DeploymentItem = NUnit.Framework.DescriptionAttribute;
 ＃万一

TestDriven.Net插件很好，也不是很昂贵...仅使用普通的VS2008，您必须从测试类或测试列表中找到测试。使用TestDriven.Net，您可以直接从要测试的类中运行测试。毕竟，单元测试应该易于维护并且靠近开发人员。

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

1. 现在，2008版可以在专业版本中使用（在需要昂贵的VS版本之前，这仅用于开发人员单元测试。）这使许多开发人员只能选择开放/外部测试框架。
2. 内置由单个公司支持的API。
3. 使用相同的工具来运行和创建测试（您可以使用命令行以及MSTest来运行它们）
4. 简单的设计（不提供Mock框架，但这对许多程序员来说是一个很好的起点）
5. 授予了长期支持（我仍然记得nDoc发生了什么，我不想提交可能在5年内无法获得支持的测试框架，但我仍然认为nUnit是一个很好的框架。）
6. 如果使用Team Foundation Server作为后端，则可以通过简单的方式使用失败的测试数据创建工作项或错误。

我已经使用NUnit 2年了。一切都很好，但是我不得不说VS中的Unit系统非常不错，因为它位于Gui中，可以更轻松地进行私有功能测试而不必弄乱。另外，VS的单元测试使您可以进行覆盖和其他NUnit不能完成的工作。

Visual Studio测试框架的一个小麻烦之处在于，它会创建许多测试运行文件，这些文件往往会使您的项目目录杂乱无章-尽管这没什么大不了的。

另外，如果您缺少诸如TestDriven.NET之类的插件，则无法像内置Microsoft VS测试框架一样在Visual Studio环境中调试NUnit（或MbUnit，xUnit等）单元测试。

稍微偏离主题，但是如果您使用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

XUnit是未开发项目的另一种可能性。它可能具有更直观的语法，但实际上与其他框架不兼容。

http://www.codeplex.com/xunit

我在NUnit上使用VS单元测试的主要要点是VS测试的创建倾向于注入一堆生成的代码以供私有成员访问。

有些人可能想测试自己的私有方法，有些人可能不想，这是一个不同的话题。

我担心的是，当我编写单元测试时，应该严格控制它们，以便我确切地知道我在测试什么以及如何进行测试。如果有自动生成的代码，我将失去部分所有权。

我同时使用了两者的TDD，（也许我有点傻）nUnit似乎对我来说使用起来更快，更简单。当我说很多的时候，我的意思是很多。

在MS Test中，到处都有太多的属性-进行真正测试的代码是您可能在此处和此处可能会读到的一小行。一团糟。在nUnit中，执行测试的代码只是控制了属性，正如它应该做的那样。

另外，在nUnit中，您只需要单击要运行的测试（只有一个？所有测试都覆盖一个类？一个程序集？一个解决方案？）。一键。而且窗户是干净的，很大的。您会获得清晰的绿色和红色指示灯。你真的知道一见钟情。

在VSTS中，测试列表卡在屏幕底部，它又小又丑。您必须查看两次才能知道发生了什么。而且您不能只运行一个测试（嗯，我还没有发现！）。

但是我当然错了-我刚刚读了大约21篇关于“如何使用VSTS进行简单TDD”的博客文章。我应该阅读更多，您是对的。

对于nUnit，我读了一篇。我是在同一天TDD。玩得开心。

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

祝一切顺利。西尔万

我收到消息“ 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

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

首先，我想纠正一个错误的陈述：您可以使用命令行在Visual Studio外部运行msTest。尽管像TeamCity这样的几种CI工具对NUnit都有更好的支持（随着msTest变得越来越流行，它可能会改变）。在我当前的项目中，我们同时使用了两者，并且发现的最大区别是mstest始终以32位运行，而NUnit以32位或64位测试运行，这仅在您的代码使用依赖于32/64的本机代码时才重要。

我从MSTest开始，但出于一个简单的原因进行了切换。MSTest不支持从其他程序集继承测试方法。

我讨厌多次编写同一测试的想法。特别是在大型项目中，测试方法可以轻松地进行100多个测试。

NUnit确实可以满足我的需求。NUnit唯一缺少的是Visual Studio插件，它可以显示每个测试的红色/绿色状态（如VSTS）。

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

如果您正在考虑使用MSTest或nUnit，那么我建议您看一下mbUnit。我的原因是

1. TestDriven.Net兼容性。没有任何节奏将TestDriven.Net.ReRunWithDebugger绑定到键盘组合。
2. Gallio框架。Gallio是nUnits之类的测试跑步者。唯一的区别是，它不在乎是用nUnit，msTest，xUnit还是mbUnit编写测试。他们都跑了。
3. 与nUnit的兼容性。mbUnit支持nUnit中的所有功能。我认为您甚至不需要更改属性（必须进行检查），只需更改参考和使用即可。
4. 集合断言。mbUnit有更多的Assert案例，包括CollectionAssert类。基本上，您不再需要编写自己的测试来查看两个集合是否相同。
5. 组合测试。如果您可以提供两组数据并为所有数据组合进行测试，那不是很酷。它在mbUnit中。

我最初是因为mbUnit的[RowTest ....]功能而选择的，但我没有找到返回的唯一理由。我将所有活动的测试套件从nUnit移开，再也没有回头。从那时起，我将两个不同的开发团队转换为收益。

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

• NUnit
• 单位
• 微软测试
• 单位

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

如果您只是开始进行单元测试，那么它可能并没有太大的区别。一旦掌握了速度，就可以更好地判断哪种框架最适合您的需求。

我不喜欢VS内置的测试框架，因为它迫使您创建一个单独的项目，而不是将测试作为要测试的项目的一部分。

MSTest本质上是对NUnit稍作修改的，具有一些新功能（例如装配设置和拆卸，而不仅仅是夹具和测试级别），并且缺少了一些最佳功能（例如新的2.4约束语法）。NUnit更成熟，其他供应商也对此提供了更多支持。当然，由于它始终是免费的（而MSTest仅使其成为了2008年的专业版，而在此之前它是更昂贵的SKU），所以大多数ALT.NET项目都使用它。

话虽这么说，有些公司还是非常不情愿地使用没有微软标签的东西，尤其是OSS代码。因此，拥有正式的MS测试框架可能是这些公司需要进行测试的动机；老实说，最重要的是测试，而不是使用什么工具（使用上面的Tuomas Hietanen的代码，您几乎可以使您的测试框架互换）。

随着.NET 4.0中代码合同系统的发布以及静态检查器的可用性，从理论上讲，您将需要编写更少的测试用例，而类似Pex的工具将可以帮助识别这些用例。与此相关的是，如果您的合同覆盖了您的尾巴，如果您需要做更少的单元测试，那为什么不继续进行并使用内置的组件，因为这减少了管理的依赖。这些天，我全都在追求简单。:-)

也可以看看：

• Microsoft Pex –自动化单元测试
• 使用Visual Studio 2010和C＃4.0使用Pex进行单元测试生成

我宁愿使用MS的小型测试框架，但目前仍坚持使用NUnit。MS的问题通常是（对我而言）

• 必须维护的共享“测试”文件（无意义）
• 测试列表导致与多个开发人员/ VCS发生冲突
• 集成UI差-设置混乱，测试选择繁重
• 没有好的外部跑步者

注意事项-如果我正在测试一个aspx站点，我肯定会使用MS-如果我自己开发，也可以使用MS-如果我的技能有限并且无法配置NUnit :)

我发现编写测试并启动NUnitGUI或其他前端之一要容易得多（testDriven远远被高估了）。使用命令行版本设置调试也很容易。