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

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

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

参见:

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

我已经使用NUnit两年了。一切都很好，但是我不得不说Visual Studio中的单元测试系统非常好，因为它在GUI中，可以更容易地对私有函数进行测试，而不必搞得乱七八糟。

此外，Visual Studio的单元测试允许你做覆盖和其他NUnit单独不能做的事情。

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

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

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

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

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

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

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