单元测试框架实际上并不重要，因为你可以用单独的项目文件和条件编译转换测试类(就像这样，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。Net中，您可以直接从正在测试的类中运行测试。毕竟，单元测试应该易于维护，并且离开发人员很近。

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

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

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

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

NUnit 运行工具 MSTest xUnit

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

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

我用这两种方法做过一些TDD，(也许我有点笨)NUnit对我来说似乎更快更简单。我说的很多，就是很多。

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

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

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

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

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

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

MSTest is essentially NUnit slightly reworked, with a few new features (such as assembly setup and teardown, not just fixture and test level), and missing some of the best bits (such as the new 2.4 constraint syntax). NUnit is more mature, and there is more support for it from other vendors; and of course since it's always been free (whereas MSTest only made it into the Professional version of Visual Studio 2008, and before that it was in way more expensive SKUs), and most ALT.NET projects use it.

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

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

参见:

微软Pex -自动化单元测试 使用Visual Studio 2010和c# 4.0与Pex生成单元测试