visual-studio NUnit 与 Visual Studio 2010 的 MSTest？

NUnit vs Visual Studio 2010's MSTest?

提问by David White

I realise that there are many older questions addressing the general question of NUnit v MSTest for versions of Visual Studio up to 2008(such as this one).

我意识到有许多较旧的问题解决了 NUnit v MSTest 的一般问题，适用于 2008 年之前的 Visual Studio 版本（例如this one）。

Microsoft have a history of getting things right in their 3rd version. For MSTest, that is VS2010.

微软有在他们的第三个版本中把事情做好的历史。对于 MSTest，即 VS2010。

Have they done so with MSTest? Would you use it in a new project in preference to NUnit?

他们用MSTest这样做了吗？你会在新项目中使用它而不是 NUnit 吗？

My specific concerns:

我的具体问题：

• speed
• running tests within CruiseControl.NET (either commandline or MSBuild task)
• code coverage reports from CC.NET
• can you run MSTest tests in debug mode

• 速度
• 在 CruiseControl.NET 中运行测试（命令行或 MSBuild 任务）
• 来自 CC.NET 的代码覆盖率报告
• 你能在调试模式下运行 MSTest 测试吗

(We use ReSharper, so test-runners are not an issue for us. We have used NUnit for the last few years. We do not have TFS.)

（我们使用 ReSharper，所以测试运行器对我们来说不是问题。过去几年我们一直使用 NUnit。我们没有 TFS。）

采纳答案by Andrey

• List item speed is same, but MsTest may be a bit slower because it creates folder for test run every time
• MSBuid and CC.Net is big pain. You can't run MSTest on computer without VS on it (not 100 sure about 2010, but with 2008 it is so)
• not sure, sorry
• yes you can, from visual studio

• 列表项速度相同，但 MsTest 可能会慢一点，因为它每次都会创建用于测试运行的文件夹
• MSBuid 和 CC.Net 是个大问题。你不能在没有 VS 的计算机上运行 MSTest（2010 年不确定，但 2008 年确实如此）
• 不确定，抱歉
• 是的，你可以，来自视觉工作室

My recommendation is following: if NUnit satisfies you - use it, forget about MSTest

我的建议如下：如果 NUnit 满足您 - 使用它，忘记 MSTest

回答by Euan Garden

To correct some old information on the thread;

更正线程上的一些旧信息；

1. It IS possible to run 64 bit tests in 2010
2. From VS2008 forward it is not neccesary to have MSTEST create directories anc opy the binaries in, just disable deployment, in 2010 thats the default but you have to set it in 2008
3. 2010 MSTEST is faster but as its a generalised test framework that also runs load/web/UI tests there are compromises in the design that will lead to it being slower. Jamie Cansdale appears to have managed to get perf increases with the lastest releases of TestDriven.net's support for MSTEST

1. 2010 年有可能运行 64 位测试
2. 从 VS2008 开始，没有必要让 MSTEST 创建目录并在其中添加二进制文件，只需禁用部署，2010 年这是默认设置，但您必须在 2008 年设置它
3. 2010 MSTEST 速度更快，但由于它是一个通用的测试框架，还运行负载/Web/UI 测试，因此在设计中存在折衷，这将导致它变慢。随着最新版本的 TestDriven.net 对 MSTEST 的支持，Jamie Cansdale 似乎已经设法提高了性能

回答by Frank Schwieterman

I've mainly used NUnit, some xUnit and some MSTest. They seem functionality equivalent, but I don't like the MSTest test runner. It runs in visual studio so it either crowds the screen or is on another monitor getting in the way everytime I tab to visual studio. (I run NUnit on another monitor, but it doesn't cover everything on that monitor everytime I focus visual studio). It takes too many clicks to find out what test failed and why.

我主要使用过 NUnit、一些 xUnit 和一些 MSTest。它们看起来功能相同，但我不喜欢 MSTest 测试运行器。它在 Visual Studio 中运行，所以它要么挤在屏幕上，要么在另一台显示器上挡住我每次切换到 Visual Studio 的方式。（我在另一台显示器上运行 NUnit，但每次我聚焦 Visual Studio 时它并没有涵盖该显示器上的所有内容）。需要点击太多次才能找出失败的测试以及原因。

NUnit can run in the background until a test fails, at which point it shows you information about the breaking test. This seems like the ideal for keeping red/green/refactor going smoothly.

NUnit 可以在后台运行，直到测试失败，此时它会向您显示有关中断测试的信息。这似乎是保持红色/绿色/重构顺利进行的理想选择。

回答by Preet Sangha

Nope. Same issues regarding appdomains and assembly resolving still exist. I would avoid unless you want the new goodness for other functional testing or integration with Team System.

不。关于应用程序域和程序集解析的相同问题仍然存在。除非您想要其他功能测试或与 Team System 集成的新优点，否则我会避免。

回答by bjornhol

If you think you'll ever run your tests in 64 bit mode, use NUnit. MsTest is only x86.

如果您认为您将在 64 位模式下运行您的测试，请使用 NUnit。MsTest 只是 x86。

回答by Nathan Tregillus

I don't know much about CruseControl.net, but you can debug tests. We currently don't use TFS either, and the MSTest is working for us.

我对 CruseControl.net 了解不多，但您可以调试测试。我们目前也不使用 TFS，MSTest 正在为我们工作。

回答by Ryan Lundy

One major difference between the two is that MSTest makes a copy of the current DLLs every time it runs a test. If you're doing TDD and running your tests frequently, this can eat up a lot of hard drive space.

两者之间的一个主要区别是 MSTest 每次运行测试时都会制作当前 DLL 的副本。如果您正在执行 TDD 并经常运行测试，这可能会占用大量硬盘空间。

If you're using MSTest, you can change this setting in Tools > Options > Test Tools > Test Execution. "Limit number of old Test Results to" is set to 25 by default in Visual Studio 2010. I usually change it to 1.

如果您使用 MSTest，则可以在工具 > 选项 > 测试工具 > 测试执行中更改此设置。在 Visual Studio 2010 中，“将旧测试结果的数量限制为”默认设置为 25。我通常将其更改为 1。

回答by mischka

MSUnit runs your test cases under conditions that are different from the actual execution environment. Specifically, the deployed files differ from those that are deployed when you run your actual project. Nethertheless, there is the [DeploymentItem]-Attribute to specify which files shall be deployed by MSUnit. So if your application depends on any external files, such as

MSUnit 在不同于实际执行环境的条件下运行您的测试用例。具体来说，部署的文件与运行实际项目时部署的文件不同。尽管如此，还是有 [DeploymentItem]-Attribute 来指定哪些文件应由 MSUnit 部署。因此，如果您的应用程序依赖于任何外部文件，例如

• database files
• database configuration file
• application configuration file
• ...

• 数据库文件
• 数据库配置文件
• 应用程序配置文件
• ...

then MSUnit is not the right choice, because the MSUnit tests never cover what your file system is going to look like in execution environment. The Visual Studio Project File settings for deploying files (Copy always, Content, etc.) are ignored by the MSUnit runner. So those settings cannot be tested.

那么 MSUnit 不是正确的选择，因为 MSUnit 测试永远不会涵盖您的文件系统在执行环境中的样子。MSUnit 运行程序会忽略用于部署文件（始终复制、内容等）的 Visual Studio 项目文件设置。因此无法测试这些设置。