关于Visual Studio 2008：如何使用MSTest / VS2008缓解TDD

我一次又一次地读到，与其他测试框架(例如nUnit，MBUnit等)相比，使用MSTest进行TDD /测试首先要困难得多。有哪些建议的手动解决方法和/或建议的第三方建议？ 由于基础架构政策，MSTest是唯一的选择吗？ 我主要是想知道VS 2008 Team Suite，但是我想开始使用VS 2008 Pro的技巧也很合适，因为这些版本现在也包含一些MSTest功能。

MSTest当然不如某些开源框架有效或可扩展，但它是可行的。由于该问题是关于使用MSTest使生活更轻松而不是替代方法，因此这里是我的MSTest提示。

• 捷径。就像Haacked所说的那样，花几秒钟来学习捷径。
• 当前上下文。由于MSTest太慢，因此，请尽可能在当前上下文中运行测试。 (CTRL + R，CTRL + T)。如果您的光标在测试方法中，则只会运行该方法。如果您的光标在方法之外，但在测试类中，则仅运行测试。并带有名称空间等
• 高效的测试和组织。狗慢。通过编写有效的测试来使事情尽可能的好。将慢速测试移至其他测试类或项目，以便您可以更频繁地运行快速测试。
• 使用WCF进行测试。如果要测试服务，请确保进行调试测试而不是RUN测试，以便Visual Studio可以启动ASP.NET开发Web服务器。在完成这些操作之后，您可以返回到RUN，但是始终进行调试可能会更容易，因此您不必考虑它。
• 配置文件。编辑您的测试运行配置，以将.config文件移动到测试执行文件夹中。
• 与Source Safe集成。您需要意识到MSTest讨厌SourceSafe，而且感觉是相互的。由于MSTest希望将测试文件置于源代码管理下，并将其添加到解决方案中，因此，每次运行测试时，它都必须签出解决方案。因此，SourceSafe必须以多重签出模式运行，以避免杀死其他开发人员。
• 忽略绒毛使用MSTest，您会获得许多不同的窗口和视图。测试运行，测试视图，测试列表...它们都没有什么用。坚持测试结果，您会更加快乐。
• 坚持"单元测试"。添加新测试时，可以添加有序测试，单元测试或通过向导运行。坚持简单的简单单元测试。

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

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

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

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

即使是静态的ClassInitialze和Cleanup，以及每个测试都具有唯一的TestContext的问题，都是因为下一代-至少对于MS语言的Windows业务程序员而言-并行编程概念。

我不幸地在一个拥有成千上万个单元测试的项目中工作。他们过去几乎占用了大部分构建时间！使用MSTest，我们可以将时间缩短到非常可管理的时间范围。

我的同事Mike Hadlow很好地总结了为什么我们完全不喜欢MSTest。

他设法将其从项目中删除，但我目前正在从事一个涉及更多政治事务的大型项目，因此我们仍在使用它。

结果是，实施MSTest的任何人都不了解TDD。我很抱歉听起来像是M $破烂者-我真的不是。但是我很烦恼我不得不忍受一个非常糟糕的工具。

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

另外，MSTest相当慢，这是因为在每个测试之间，它都会为每个测试重建整个上下文，这可以确保以前的测试-失败或不影响当前的测试，但是会降低速度。但是，您可以使用/ noisolation标志，它将在MSTest进程中运行所有测试-更快。
要在IDE中加速，请执行以下操作：在VS IDE中，可以转到"工具"-"选项"，然后选择"测试工具"。选择名为"测试执行"的子项目，并在右侧的对话框中，确保选中"保持测试执行引擎在两次测试之间运行"复选框。

• MSTest具有"高摩擦"：获取
  使用NAant和MbUnit的构建脚本
  与MStest和MSBuild相比。没有
  比较。
• MSTest是慢的MbUnit
  和NUnit在我的经验上更快
  (gallio在这里可能会有所帮助)
• MStest添加了一个
  一堆我不需要的东西
  有线配置文件等
• MSTest没有其他操作系统测试框架。签出xUnit和MbUnit

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

mstest有许多配置文件，因此操作性较差。
我选择mbunit的另一个原因是mbunit的"回滚"功能。这使您可以回滚在此测试中完成的所有数据库操作，因此您实际上可以进行全电路测试，而不必担心测试后池被污染。
在mstest中也缺少RowTest工具。

我建议仅在构建过程中将mbunit作为依赖项运行，它很容易将其与bin一起浮动，并提供引用，无需安装。

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

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

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

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

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

这意味着编写断言需要花费更多的代码，而测试运行速度慢则意味着整个过程比NUnit慢。
开源选项在社区中也提供了更多支持。

如果您将TFS用于CI，则需要跳过几个步骤才能使NUnit发布测试结果。相比之下，使用MSTest在TFS上运行测试非常简单明了。
如果您不喜欢TFS，而不是我会一直使用NUnit，那就更好了。

要回答一个非针对性的问题，我的答案是
"可能NUnit只是不露面。"

免责声明：我没有使用xUnit的MS版本的实际经验，但是我听到诸如"您需要安装庞大的想法才能在单独的计算机上运行测试"之类的问题-这是完全不可以的。
除此之外，MS还可以通过某种与整个想法背道而驰的IDE铃声/口哨，为新手提供正确的路径。就像从类生成测试一样，我记得大约一年以前了。这打破了测试驱动的整个要点-您的设计应该从RGR的微小步骤中产生：编写测试使其通过重构。如果您使用该工具，则会失去整个体验。

我将停止我的讲道..现在:)