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

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

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

另外，如果你缺少一个像TestDriven这样的插件。NET，你不能在Visual Studio环境中调试你的NUnit(或MbUnit, xUnit等)单元测试，而你可以在Microsoft Visual Studio测试框架中进行，这是内置的。

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

NUnit 运行工具 MSTest xUnit

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

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

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

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

NUnit正是我所需要的。NUnit唯一缺少的是Visual Studio插件，它可以显示每个测试的红色/绿色状态(就像VSTS一样)。

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

参见:

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

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

TestDriven.Net compatibility. Nothing beats have TestDriven.Net.ReRunWithDebugger bound to a keyboard combination. The Gallio framework. Gallio is a test runner like NUnit's. The only difference is it doesn't care if you wrote your tests in NUnit, MSTest, xUnit or MbUnit. They all get run. Compatibility with NUnit. All features in NUnit are supported by MbUnit. I think you don't even need to change your attributes (will have to check that), just your reference and usings. Collection asserts. MbUnit has more Assert cases, including the CollectionAssert class. Basically you no longer need to write your own tests to see if two collections are the same. Combinatorial tests. Wouldn't it be cool if you could supply two sets of data and get a test for all the combinations of data? It is in MbUnit.

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