有什么我可以在 NUnit 中做但在 MSTest 中不能做的事情吗？

Question

这个问题已经在许多不同的论坛上以各种形式提出，但是，恕我直言，我一直无法找到一个真正明确回答这个问题的地方，所以我将重新构建它并再次询问它。

我基本上在一家微软商店工作。我们使用 TFS，并且所有开发人员都订阅了 MSDN，包括 VS 的 Team Suite 版本。这样我们就可以访问MSTest了。

我阅读了各种 NUnit 与 MSTest 的比较，开发人员社区似乎绝大多数选择了 NUnit。但给出的理由似乎从来都不是压倒性的或令人信服的，至少对于我们的情况来说是这样。 （NUnit 更新更频繁，NUnit 更快，NUnit 不需要 TFS 等）

如果我选择，我可以使用 NUnit，但必须捍卫在没有正式支持的情况下使用开源软件的行为。我需要一个相当令人信服的理由才能这样做。

为了证明使用 NUnit 而不是 MSTest 的合理性，我基本上必须回答的是：有什么是我在 NUnit 中可以做而在 MSTest 中无法做的事情吗？

Answer 1

• NUnit 包含一个 [TestCase] 属性，允许实现参数化测试。这在 MSTest 中并不是开箱即用的 - 但可以通过可扩展性来完成。
• MsTest 的 ExpectedException 属性有一个错误，即预期消息永远不会真正断言，即使它是错误的 - 测试将通过。
• NUnit 附带一个 Assert.Throws API，允许在特定代码行而不是整个方法上测试异常。 MSTest 也有类似的功能（由为 NUnit 实现的同一个人实现），但不随 MSTest 一起提供。
• NUnit 包含开箱即用的断言 API 的流畅版本。 MSTest 有第三方扩展可以执行此操作，但没有随 MSTest 一起提供。
• NUnit 允许抽象类作为测试装置（因此您可以继承测试装置）。 MsTest 允许这样做，但将抽象类限制为单个程序集。
• NUnit 允许非公共类作为测试装置（从最新版本开始）
• NUnit 是专门为了单元测试的想法而创建的。 MSTest 是为测试而创建的 - 也是一些单元测试。
• NUnit 包含 PNunit（与 NUnit 运行并行测试）。 MSTest 在 Visual Studio 2010 中添加了此功能，可通过 XML 配置

Answer 2

Roy，你的一些信息已经过时了，尤其是与 2010 年相关的信息；

<块引用>

Nunit 包含一个 [TestCase] 属性，允许实现参数化测试。这在 MSTest 中不存在

这可以使用 2010 年的单元测试扩展性来实现。

<块引用>

MSTest 的 ExpectedException 属性有一个错误，即预期消息永远不会真正断言，即使它是错误的 - 测试将通过。

正确那仍然存在

<块引用>

NUnit 有一个 Assert.Throws API，允许在特定代码行而不是整个方法上测试异常（不过您可以自己轻松实现这个）

Jim 在执行 MSTest 的同时为 MSTest 实现了 Assert.Throws 的一个版本NUnit 的原始实现，NUnit 已包含在后续版本中，MSTest 尚未包含，但仍然可以使用。

<块引用>

NUnit 包含 Assert API 的流畅版本（如前所述 - Assert.That..）

其中有几个由第三方为 MSTest 实现

<块引用>

NUnit 更快

请参阅 Jamie 的评论，他已设法使 MSTest 运行得更快:-)

<块引用>

NUnit 可以在 32 位和 64 位中运行测试（MSTest 仅在 32 位 IIRC 中运行它们）

不是在 2010 年，内置了 64 位支持。

<块引用>

NUnit 允许抽象类作为测试装置（因此您可以继承测试装置）。 MsTest 没有。

这可以工作，但不能跨程序集，这确实限制了它的实用性。

<块引用>

NUnit 允许非公共类作为测试装置（从最新版本开始）

仍然存在

<块引用>

NUnit 是专门为了单元测试的想法而创建的。 MSTest 是为测试而创建的 - 也是一些单元测试。

正确的是，有很多误解认为 MSTest 与 Nunit 相同，但 MSTest 是一个通用框架。

<块引用>

NUnit 包含 PNunit（与 NUnit 运行并行测试）。 MSTest只是在vs 2010中添加了这个能力

正确的是，有一个 XML 配置设置允许控制并行度。

Answer 3

NUnit 有一个更丰富的断言 API。该 API 特别优雅（甚至流畅），例如，

Assert.That(Is.Unique, myResults);  // assert: myResults is a collection of unique items

如果您看过 Hamcrest< /a> JUnit 的扩展，您会认出这种风格。

它还具有不断增长的扩展集，例如性能测试和优秀的 VS 插件。

Answer 4

我可以向您推荐一些有关 MSTest 的挫败感的博客：

• MSBuild、NAnt、NUnit、MSTest 和挫折
• 使用 MSTest 清理构建服务器 == FAIL

公平地说，这些人正在尝试在非 TFS 构建服务器上设置 MSTest 。他们的一些问题不适用于您的情况。

我们主要是一家 Microsoft 商店，并使用 TFS 进行源代码控制。但是，我们使用 TeamCity 进行持续集成；我们喜欢它，并且它与 TFS 集成得相当好。我从未使用过 MSTest；我们已经使用 NUnit 多年了，并且没有看到任何改变的理由。

MSTest 应该与 Team Suite 紧密集成，这（因为您的公司已经为此支付了高昂的费用）是对其有利的一点。

NUnit 的供应商锁定较少，并且具有丰富的 API。正如 serg10 所指出的，Assert.That 语法特别强大且优雅。

最后，您可以编写良好的单元测试，而无需所有花哨的功能。其中一些甚至可能会妨碍（这是 xUnit.net 背后的理论）。我建议您的团队标准化一个测试框架；避免一些代码在 MSTest 中，而其他代码在 NUnit 中。

我认为编写好的测试比选择框架更重要。考虑阅读单元测试的艺术：.NET 中的示例，编写一些测试，然后看看 MSTest 是否足以满足您团队的需求。

编辑：《单元测试的艺术》附录 B 对 Microsoft 的单元测试框架有一些很好的评论。它提到 YUnit 作为扩展 MSTest 有多么麻烦的示例。然而，由于紧密集成，作者确实建议 Team System 用户使用 MSTest。

Answer 5

我在 MsTest 和 NUnit 之间有一个很好的方法。
您可以使用 MSTest 框架来运行测试（每个测试的 TestClass 属性和 TestMethod 属性），但使用 NUnit Assert API。

只需这样做：

using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert;  

现在您可以使用 Assert.That(..) 并且仍然拥有 TFS 自动构建和测试报告。
你的测试可以在VS、TestDriven.net或Resharper中运行，没关系，测试会失败或正确通过，失败输出将根据NUnit框架。

参见这里：
http:// /alsagile.com/archive/2010/03/09/stop-the-war- Between-nunit-and-mstest-make-them.aspx

Answer 6

1. MSTest 测试运行程序是非确定性的，这足以让您不敢使用它。我无法使用集成测试运行程序从 TFS 2010 持续运行 MSTest；它会在项目构建和构建代理之间出现一些不同的错误消息（并且不一致）。
2. MSTest 有时（并非始终）会因为泄漏内存而中断 - 即使使用最新版本的 Visual Studio，内存不足异常仍然会发生。这个问题的解决方法很糟糕。
3. 我对 MSTest 还有其他一些小问题，并且在博客中写了一些一般使用 MSTest 的解决方法： http: //www.pseale.com/blog/TFSAsYourBuildCIServerOnlyPositiveTakeaways1Of2.aspx

我在将我们从 MSTest 切换到 NUnit 时发现了这个问题，因为由于 MSTest，我们无法再信任 CI 构建的结果。切换到 NUnit 将使我们（最终）相信 CI 构建失败是真实的，而不是另一个 MSTest 故障。这是真正的答案——只有使用 NUnit（或其他一些非 MSTest 测试运行程序）我们才能信任我们的 CI 构建。

Answer 7

请仔细阅读 ExpectedExceptionAttribute 文档，没有任何地方说明测试异常消息，因此这不是未断言的错误。

第二个参数是未抛出预期异常类型时显示的断言消息，而不是预期异常消息。即像 Assert.IsTrue(condition, message) 中的第二个参数一样。

Answer 8

我一直致力于 TestDriven.Net 3.0 中对 MSTest 的一流支持。在以前的版本中，MSTest 支持非常基本（似乎很少有人使用 MSTest）。

从 TestDriven.Net 3.0 Beta 2 开始，对 MSTest 的所有单元测试相关属性都有相当全面的支持。甚至还支持使用 DataSource 属性的数据驱动测试。您的测试也将以接近 NUnit 的速度执行！

如果您使用 MSTest，我很想知道在使用 TestDriven.Net 3.0 Beta 2（或更高版本）执行时是否有任何单元测试失败。

请在您的 MSTest 项目中尝试一下，并让我知道您的进展情况：
http://www.testdriven.net/download.aspx

注意，它不支持DeploymentItem 或 HostType 属性。您可以使用“复制到输出目录”项目项设置而不是 DeploymentItem。

Answer 9

您可以更改 NUnit 中的代码，因为它是开源的。 MSTest 无法做到这一点。

Answer 10

请参阅 http:// Fluentassertions.codeplex.com。你可以做类似的事情

"ABCDEFGHI".Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

new[] { 1, 2, 3 }.Should().HaveCount(4, "because we thought we put three items in the 
collection"))

dtoCollection.Should().Contain(dto => dto.Id != null);

collection.Should().HaveCount(c => c >= 3);

dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer);

dt1.Should().BeWithin(TimeSpan.FromHours(50)).Before(dt2); 

Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon);
action
   .ShouldThrow<RuleViolationException>()
   .WithMessage("Cannot change the unit of an existing ingredient")
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity

Answer 11

@戴夫·汉纳
MS Test 开箱即用，因此减少了一个需要担心部署和保持更新的组件。
它还在设计上与 Visual Studio 和其他 Microsoft 产品集成。

流畅的语法很好，但它不是功能上的差异，所以我会忽略它。更不用说您可以通过使用扩展库在 MS Test 中拥有相同的功能。

表现。 99% 的测试性能由被测系统控制，因此即使两个库之间有 100% 的性能差异，也会导致性能的总体差异可以忽略不计。

开源与非开源：您从使用开源库中受益的机会很小。例外情况是当更改经常被拉入主干或有足够的资源来保持修改的分支更新时。

Answer 12

您可以非常轻松地使用 Mono 在 Linux 上运行 NUnit 测试，但我认为您不能通过 MSTest 测试来做到这一点。