如果你正在考虑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移过来，再也没有回头。从那时起，我已经将两个不同的开发团队转换为收益。

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

The 2008 version now is available in professional editions (before it required expensive versions of Visual Studio, and this is just for developer unit testing) that left a lot of developers with the only choice of open/external testing frameworks. Built-in API supported by a single company. Use the same tools to to run and create tests (you may run them using the command line also MSTest). Simple design (granted without a mock framework, but this is a great starting point for many programmers). Long term support granted (I still remember what happened to NDoc, and I don't want to commit to a testing framework that might not be supported in five years, but I still consider NUnit a great framework). If using Team Foundation Server as your backend, you can create work items or bugs with the failed test data in a simple fashion.

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

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

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

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

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

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

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

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

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

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

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

NUnit 运行工具 MSTest xUnit

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

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