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

感谢帮助和建议！

解决方案

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

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

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

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

单元测试框架实际上并不重要，因为我们可以使用单独的项目文件和条件编译来转换测试类。
(例如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，我们可以直接从要测试的类中运行测试。毕竟，单元测试应该易于维护并且靠近开发人员。

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

http://www.codeplex.com/xunit

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

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

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

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

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

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

同样，如果我们缺少诸如TestDriven.NET之类的插件，则无法像内置Microsoft VS测试框架一样在Visual Studio环境中调试NUnit(或者MbUnit，xUnit等)单元测试。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我已经使用了两者，并且(也许我有点笨)使用了一些TDD，对我而言，nUnit似乎要更快，更简单。当我说很多话时，我的意思是很多。

在MS Test中，属性太多了，执行真实测试的代码到处都是我们可能在此处和此处阅读的细线。一团糟。在nUnit中，执行测试的代码仅控制属性，正如它应该做的那样。

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

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

但是我可能是错的，我当然只读了大约21篇关于"如何使用VSTS进行简单TDD"的博客文章。我应该阅读更多，我们是对的。

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

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

一切顺利。
西尔万

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

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

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

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

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

也可以看看：

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