如何使用MSTest / VS2008缓解TDD

Question

我一次又一次地读到，使用MSTest进行TDD /测试比使用其他测试框架（如nUnit，MBUnit等）更困难......有什么建议的手动变通方法和/或第三方位你建议什么时候MSTest是基础设施政策的唯一选择？我主要想知道的是VS 2008 Team Suite，但我认为VS 2008 Pro的提示也适用，因为现在还有一些MSTest功能。

Answer 1

MSTest肯定不像某些开源框架那样高效或可扩展，但它是可行的。由于这个问题要求使用MSTest使生活更轻松而不是替代品，这里是我的MSTest提示。

• 的快捷键即可。就像哈克德所说，花几秒钟来学习捷径。
• 当前情境。由于MSTest速度很慢，因此只能在当前上下文中运行测试。 （ CTRL + R ， CTRL + T ）。如果光标在测试方法中，则只运行该方法。如果光标位于方法之外，但在测试类中，则只会运行测试。并使用命名空间等等
• 高效的测试和组织。它的狗很慢。通过编写有效的测试，尽可能做到最好。将慢速测试移动到其他测试类或项目，以便您可以更频繁地运行快速测试。
• 使用WCF进行测试。如果您正在测试服务，请确保进行DEBUG测试而不是RUN测试，以便Visual Studio可以启动ASP.NET开发Web服务器。在这些之后，你可以回到RUN，但是总是可以更容易调试，所以你不必考虑它。
• 配置文件。编辑测试运行配置以将.config文件移动到测试执行文件夹中。
• 与源安全集成。你需要知道MSTest讨厌SourceSafe，感觉是相互的。由于MSTest希望将测试文件置于源代码管理之下，并将它们添加到解决方案中，因此每次运行测试时都必须检查解决方案。因此，SourceSafe必须以多次检出模式运行，以避免杀死同事。
• 忽略绒毛使用MSTest，您可以获得十几个不同的窗口和视图。测试运行，测试视图，测试列表......它们都不太有帮助。坚持测试结果，你会更快乐。
• 坚持“单元测试”。添加新测试时，可以添加有序测试，单元测试或通过向导运行。坚持简单的单元测试。

Answer 2

如果您别无选择，只能使用MSTest，请了解键盘快捷键。他们会让你的生活更轻松。

在当前背景下测试： CTRL + R ， T
解决方案中的所有测试： CTRL + R ， A

当前上下文中的调试测试： CTRL + R ， CTRL + T
调试解决方案中的所有测试： CTRL + R ， CTRL + A

Answer 3

我很好奇。我不明白的是人们开始比较MSTest提供的所有开源工具并开始抨击它。评论它是多么笨拙，如何无知等恕我直言，这是因为它与xUnit框架有根本的不同。它针对并行执行进行了优化。

即使是具有静态ClassInitialze和Cleanup的qurik，并且每个测试都有唯一的TestContext，因为nextgen - 至少对于MS语言的Windows业务程序员来说 - 并行编程概念。

我不幸在一个有数万次单元测试的项目中工作。他们过去几乎占用了大部分的构建时间！通过MSTest，我们将其降低到非常可管理的时间线。

Answer 4

我的同事Mike Hadlow很清楚我们为什么完全厌恶MSTest here。

他设法将其从他的项目中移除，但我目前正在开展一个涉及更多政治的更大项目，所以我们仍在使用它。

它的结果是实施MSTest的人不理解TDD。我很遗憾听起来像M $ basher - 我真的不是。但我很生气，我不得不忍受一个非常糟糕的工具。

Answer 5

我没有看到任何与MSTest有关的严重问题。具体来说，你在说什么？事实上，我们正在从NUnit转向MSTest。不过，我不知道我们的原因。

Answer 6

mstest中有很多配置文件，使其不那么con。 我选择mbunit的另一个原因是mbunit的“回滚”功能。这允许您回滚在此测试中完成的所有数据库事务，因此您可以实际进行完整的电路测试，而不用担心测试后池塘被污染。
在mstest中也没有RowTest工具。

我建议只在构建过程中运行mbunit作为依赖项，它很容易用你的bin浮动它，引用，无需安装。

Answer 7

• MSTest有“高摩擦力”：获得 使用NAant和MbUnit构建脚本 与MStest和MSBuild相比。没有 比较。
• MSTest是慢MbUnit 和NUnit在我的体验中更快 （加利奥可能会有所帮助）
• MStest添加了一个 一堆我不需要的东西 有线配置文件等。
• MSTest没有其他OS测试框架的胎儿集。看看xUnit和MbUnit

它太难用了，有很多更好的选择。

Answer 8

如上所述oyu需要安装完整的IDE才能在另一台机器上使用MSTest，这有点废话。我想这是因为他们希望确保单元测试仅适用于高端视觉工作室，并且你能够以任何其他方式运行它们。

另外，MSTest非常慢，这是因为在每次测试之间它会重建每个测试的整个上下文，这使得oone确定以前的测试 - 失败或者不会影响当前的测试，但会减慢速度。但是你可以使用/ noisolation标志，它将在MSTest过程中运行所有测试 - 这样更快。 要在IDE中加速：在VS ide中，您可以转到Tools-Options，然后选择Test Tools。选择名为Test execution的子项，并在右侧的dialouge中确保选中“在测试运行之间保持测试执行引擎运行”复选框。

Answer 9

要回答一个非尖锐的问题，我的回答是 “可能NUnit只是不在你的脸上。”

免责声明：我没有使用MS版xUnit的实际经验，但是我听到了诸如“你需要安装巨大的想法只是为了在一台单独的机器上运行测试”的问题 - 这是一个完整的禁忌。 除此之外，MS还有这种方式通过某种与所有想法背道而驰的IDE铃声/哨子来扭曲新手的正确道路。就像从类中生成测试一样，我记得在一年左右的时间里就已经记得了......它打败了测试驱动的全部要点 - 你的设计应该从RGR的微小步骤中出现：写一个测试 - 让它通过重构。如果您使用该工具 - 它会剥夺您的整个体验。

我会停止我的布道..现在：）

Answer 10

我已经使用NUnit进行了多年的TDD开发，并且由于角色的改变，现在已经使用MSTest大约4个月了。

我认为MSTest不会阻止某人做TDD。你仍然拥有TDD所需的所有核心内容，例如基本断言和模拟框架（我使用Rhino Mocks）。

MSTest与Visual Studio紧密集成，此集成的最佳组件是内置的代码覆盖率工具。

BUT 使用MSTest有很多令人信服的理由不。我认为最大的两个关闭点是：

1. 缺少断言选项（与NUnit相比）
2. 缓慢的测试跑步者（与NUnit相比较慢）

这意味着写入断言需要更多代码与慢速测试运行器相结合意味着整个过程比NUnit慢。 开源选项在社区中也有更多的支持。

如果你正在使用TFS进行CI，那么你需要跳过一些箍/ hack来让NUnit发布测试结果。使用MSTest在TFS上运行测试非常简单直接。 如果你没有触及TFS而不是我一直去NUnit，它就更好了。