NUnit与MbUnit与MSTest与xUnit.net

.NET有很多单元测试框架。我发现了这个小的功能比较：http : //xunit.github.io/docs/comparisons.html

现在，我要为我们选择最佳的。但是如何？有关系吗？哪一个是最有前途的证据，并且其发展势头良好？我应该关心这些功能吗？虽然xUnit似乎是最现代的并且是专门为.NET设计的，但NUnit似乎再次被广泛接受。MSTest再次已经集成到Visual Studio中...

我知道这是一个旧线程，但是我想我应该对xUnit.NET投一个票。尽管提到的大多数其他测试框架几乎都相同，但是xUnit.NET采取了一种非常独特，现代且灵活的单元测试方法。它改变了术语，因此您不再定义TestFixtures和Tests……您可以指定关于代码的事实和理论，从TDD / BDD的角度来看，它与测试的概念更好地集成在一起。

xUnit.NET也非常可扩展。它的FactAttribute和TraitAttribute属性类不是密封的，并提供可重写的基本方法，使您可以控制如何执行这些属性修饰的方法。尽管xUnit.NET以其默认形式允许您编写与NUnit测试治具及其测试方法相似的测试类，但您完全不受限于这种形式的单元测试。你可以自由地扩展以支持BDD风格的关注/背景/观察规格的框架，描绘了这里。

xUnit.NET还通过其Theory属性和相应的数据属性直接支持即装即用型测试。适合的输入数据可以从excel，数据库甚至是自定义数据源（如Word文档）（通过扩展基本数据属性）加载。这使您可以利用单个测试平台进行单元测试和集成测试，在减少产品依赖性和所需的培训方面可以发挥巨大作用。

其他测试方法也可以使用xUnit.NET实施...可能性是无限的。结合另一个非常具有前瞻性的模拟框架Moq，两者共同创建了一个非常灵活，可扩展且功能强大的平台，用于实施自动化测试。

NUnit可能是第3方工具最受支持的。它也比其他三个更长。

我个人不太关心单元测试框架，模拟库更重要（恕我直言）（并且将您锁定在更多内容中）。只需选择一个并坚持下去即可。

我不会选择MSTest。尽管它可能是Microsoft支持的框架的最新证明，但它并不是最灵活的解决方案。没有一些技巧，它就不会独立运行。因此，很难在不安装Visual Studio的情况下在TFS以外的其他生成服务器上运行它。实际上，Visual Studio测试运行程序要比Testdriven.Net +其他任何框架都要慢。并且由于此框架的版本与Visual Studio的版本相关，因此更新较少，如果必须使用较旧的VS，则必须与较旧的MSTest绑定。

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

我个人根据同事的喜好使用XUnit.Net或NUnit。NUnit是最标准的。XUnit.Net是最精简的框架。

考虑用另一个测试框架补充而不是替换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);
        }
    }
}

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

在小规模/个人规模上这没什么大不了的，但是在较大规模上它可以迅速变成更大的事情。我的老板是一家大型的Microsoft商店，但出于多种原因，我不会/不能购买Team System / TFS。当前，我们使用Subversion + Orcas + MBUnit + TestDriven.NET，它运行良好，但是获取TD.NET却是一个巨大的麻烦。MBUnit + TestDriven.NET的版本敏感性也是一个很大的麻烦，并且拥有一个额外的商业物品（TD.NET）来进行法律审查和采购以进行处理和管理也不是一件容易的事。我的公司像许多公司一样，对MSDN订阅模型感到满足并感到满意，它只是不习惯于为数百名开发人员处理一次性采购。换句话说，在我看来，完全集成的MS产品虽然不一定总能达到最佳效果，但却是一项重大的增值服务。

我认为我们会坚持目前的步骤，因为它可以正常工作，而且我们已经在组织上克服了困难，但是我确实希望MS在此领域提供出色的产品，以便我们可以稍微巩固和简化我们的开发人员体系。

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

就像之前的人说的选择一个模拟框架一样，目前我最喜欢的是Moq。