NUnit 与 Visual Studio 2010 的 MSTest 对比？
我意识到有许多较旧的问题解决了 NUnit v MSTest 对于 Visual Studio 2008 以下版本的一般问题（例如 这个）。
微软在其第三个版本中一直致力于把事情做好。对于MSTest来说，就是VS2010。
他们是否使用 MSTest 做到了这一点？您会在新项目中使用它而不是 NUnit 吗？
我的具体关注点：
- 速度
- 在 CruiseControl.NET（命令行或 MSBuild 任务）中运行测试的
- 来自 CC.NET 的代码覆盖率报告
- 您能否在调试模式下运行 MSTest 测试
（我们使用 ReSharper，因此测试运行程序对我们来说不是问题。我们过去几年我们一直在使用 NUnit，但我们没有 TFS。）
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).
Microsoft have a history of getting things right in their 3rd version. For MSTest, that is VS2010.
Have they done so with MSTest? Would you use it in a new project in preference to 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
(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.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您认为您将在 64 位模式下运行测试，请使用 NUnit。 MsTest 仅是 x86。
If you think you'll ever run your tests in 64 bit mode, use NUnit. MsTest is only x86.
两者之间的一个主要区别是 MSTest 每次运行测试时都会生成当前 DLL 的副本。如果您正在进行 TDD 并频繁运行测试，这可能会占用大量硬盘空间。
如果您使用的是 MSTest，则可以在“工具”>“工具”>“工具”中更改此设置。选项>测试工具>>测试执行。在 Visual Studio 2010 中，“旧测试结果的数量限制为”默认设置为 25。我通常将其更改为 1。
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.
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.
MSUnit 在与实际执行环境不同的条件下运行测试用例。具体来说，部署的文件与运行实际项目时部署的文件不同。尽管如此，还是有 [DeploymentItem] 属性来指定 MSUnit 应部署哪些文件。因此，如果您的应用程序依赖于任何外部
文件，例如
那么 MSUnit 不是正确的选择，因为 MSUnit 测试永远不会涵盖文件系统在执行环境中的外观。 MSUnit 运行程序将忽略用于部署文件的 Visual Studio 项目文件设置（始终复制、内容等）。因此无法测试这些设置。
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
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.
我的建议如下：如果 NUnit 满足你 - 使用它，忘记 MSTest
My recommendation is following: if NUnit satisfies you - use it, forget about MSTest
修正线程上的一些旧信息；
To correct some old information on the thread;
我主要使用过 NUnit、一些 xUnit 和一些 MSTest。它们看起来功能相同，但我不喜欢 MSTest 测试运行程序。它在 Visual Studio 中运行，因此它要么挤满屏幕，要么在另一台显示器上，每次我点击 Visual Studio 时都会受到阻碍。 （我在另一台显示器上运行 NUnit，但每次我聚焦 Visual Studio 时它并没有覆盖该显示器上的所有内容）。需要多次点击才能找出哪些测试失败以及失败的原因。
NUnit 可以在后台运行，直到测试失败，此时它会向您显示有关中断测试的信息。这似乎是保持红/绿/重构顺利进行的理想选择。
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 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.
没有。关于应用程序域和程序集解析的相同问题仍然存在。我会避免，除非您想要其他功能测试或与团队系统集成的新优点。
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.
我对 CruseControl.net 不太了解，但你可以调试测试。我们目前也不使用 TFS，MSTest 正在为我们工作。
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.