我知道这是一个老帖子，但我想我应该为xUnit.NET投票。虽然提到的大多数其他测试框架都是差不多的，但是xUnit。NET采用了一种非常独特、现代且灵活的方法来进行单元测试。它改变了术语，因此您不再定义testfixture和Tests…你指定了关于代码的事实和理论，这从TDD/BDD的角度更好地集成了什么是测试的概念。

xUnit.NET is also EXTREMELY extensible. Its FactAttribute and TraitAttribute attribute classes are not sealed, and provide overridable base methods that give you a lot of control over how the methods those attributes decorate should be executed. While xUnit.NET in its default form allows you to write test classes that are similar to NUnit test fixtures with their test methods, you are not confined to this form of unit testing at all. You are free to extend the framework to support BDD-style Concern/Context/Observation specifications, as depicted here.

xUnit。NET还通过其Theory属性和相应的数据属性直接支持开箱即用的fit样式测试。Fit输入数据可以从excel、数据库甚至自定义数据源(如Word文档)加载(通过扩展基本数据属性)。这允许您利用单个测试平台进行单元测试和集成测试，这在减少产品依赖和所需的培训方面是巨大的。

其他测试方法也可以用xUnit.NET实现……可能性是无限的。结合另一个非常前瞻性的mock框架Moq，这两者创建了一个非常灵活、可扩展且功能强大的实现自动化测试的平台。

考虑用另一个测试框架补充而不是取代MSTest。您可以保持Visual Studio MSTest集成，同时获得功能更全的测试框架的好处。

例如，我使用xUnit与MSTest。添加对xUnit.dll程序集的引用，然后执行如下操作。令人惊讶的是，它就是工作!

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert;  // <-- Aliasing the Xunit namespace is key

namespace TestSample
{
    [TestClass]
    public class XunitTestIntegrationSample
    {
        [TestMethod]
        public void TrueTest()
        {
            Assert.True(true);  // <-- this is the Xunit.Assert class
        }

        [TestMethod]
        public void FalseTest()
        {
            Assert.False(true);
        }
    }
}

It's not a big deal on a small/personal scale, but it can become a bigger deal quickly on a larger scale. My employer is a large Microsoft shop, but won't/can't buy into Team System/TFS for a number of reasons. We currently use Subversion + Orcas + MBUnit + TestDriven.NET and it works well, but getting TD.NET was a huge hassle. The version sensitivity of MBUnit + TestDriven.NET is also a big hassle, and having one additional commercial thing (TD.NET) for legal to review and procurement to handle and manage, isn't trivial. My company, like a lot of companies, are fat and happy with a MSDN Subscription model, and it's just not used to handling one off procurements for hundreds of developers. In other words, the fully integrated MS offer, while definitely not always best-of-bread, is a significant value-add in my opinion.

我认为我们将保持当前的步骤，因为它是有效的，我们已经在组织上克服了困难，但我确实希望MS在这个领域有一个引人注目的产品，这样我们就可以巩固和简化我们的开发堆栈。

I wouldn't go with MSTest. Although it's probably the most future proof of the frameworks with Microsoft behind it's not the most flexible solution. It won't run stand alone without some hacks. So running it on a build server other than TFS without installing Visual Studio is hard. The visual studio test-runner is actually slower than Testdriven.Net + any of the other frameworks. And because the releases of this framework are tied to releases of Visual Studio there are less updates and if you have to work with an older VS you're tied to an older MSTest.

我认为你使用的其他框架并不重要。从一个转换到另一个真的很容易。

我个人使用XUnit。Net或NUnit，这取决于我同事的偏好。NUnit是最标准的。XUnit。Net是最精简的框架。

Nunit不能很好地与c++中的混合模式项目一起工作，所以我不得不放弃它

这没什么大不了的，在它们之间切换很容易。集成MSTest也不是什么大问题，只需获取testdriven.net。

就像前一个人说的选择一个嘲弄的框架，我目前最喜欢的是Moq。