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的代码，你几乎可以让你的测试框架可互换)。

我收到消息说“NUnit文件结构比VSTest更丰富”… 当然，如果你更喜欢NUnit的文件结构，你可以使用这个解决方案的另一种方式，像这样(NUnit→Visual Studio):

 #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

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

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

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

参见:

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

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

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

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.