首先是一些背景;我们正在.NET 4.5中开发一个大型的桌面WPF应用程序，目标是64位Windows 7和8.我们正在使用Visual Studio 2012.2（很快将成为.3，然后可能是2013年！）和TFS 2012（再次.2。 2013）。使用CodedUI测试测试WPF应用程序，编码的ui测试项目应共享解决方案吗？

这款产品目前都在一个大的解决方案（刚刚超过50个项目）产生一个WPF EXE，DLL文件的加载和一个不错的MSI安装它。我们使用TFS（门控和计划）来构建解决方案，其安装程序（WiX）并运行其测试（SpecFlow用于BDD和MSTest单元测试），这非常有效。

我有一个单独的调度TFS构建通过PowerShell脚本部署MSI物理试验台在一个不受信任的AD域（见TFS2012 LabDefault.11 template deploy scripts fail with “Team Foundation Server could not complete the deployment task”为参与该挑战的细节！）

OK所以那就是我的位置，现在我想把事情推向下一步; CodedUI测试驱动完整的应用程序集成测试;我想“冒烟测试”我的构建。

因此，作为一个简单的灵魂，我为我的产品解决方案添加了一个新项目;一个CodedUI测试项目。

这很高兴地运行本地安装的产品（而不是刚建立的产品;因为我最终希望CUIT在部署的测试平台上作为烟雾测试运行，并且该平台刚刚安装了我刚刚构建的MSI）并用断言执行一些UI测试。

现在我的问题是CUIT项目作为产品解决方案的一部分，本地测试运行发现并运行我的CUIT测试，这是不期望的。我只想在实验室构建测试阶段运行CUIT测试。

因此是否将CUIT项目放入产品解决方案中是一个坏主意？或它应该是一个单独的解决方案？将它们分开看起来似乎是错误的，因为它们是相关的; CUIT项目是解决方案可部署应用程序的完整堆栈集成测试。

我可以在产品解决方案中包含CUIT并停止测试运行者看到测试吗？或者只有两种解决方案更好？

有什么优点和缺点？

更新

最后，我们创建了一个包含一个编码的UI测试项目新的解决方案，并确保这是与内置的UI解决方案相同的TFS构建建。这使我们可以在本地加载和运行编码的UI测试而不会出现问题，主UI项目中的单元测试不会受到干扰。仍然看起来有些不协调，但是对于每个用户的多人团队测试设置太难以将编码的UI分解成不同的解决方案更简单。

来源

2013-06-26 Pete Stensønes

如果您可以对现有答案提供一些反馈（以保持讨论活跃） – Micha

我所做的就是制作一个解决方案，并在其中创建了一个CUIT项目，然后我在其中进行了多个Coded UI测试。这很好，因为使用orderedTest可以将它们一起运行，并且它们也共享一个UIMap，这也有帮助。

来源

2013-06-28 14:09:39 matthiasgh

我也有/有这个问题，因为我们在使用CUIT的开始。目前，CUIT仍在产品解决方案中。我们这样做是因为测试应该留在开发人员的记忆中。当测试停留在解决方案上时，恐怕他们会被遗忘。但事实上，有时候CUIT会污染产品解决方案，所以我想他们在经过一段时间后会得到自己的解决方案，并且测试已经建立。

编辑：如果您使用不同版本的Visual Studio，则必须考虑例如VS Prof.无法使用代码UI测试构建解决方案。这意味着在“多VS版本环境”中，您必须将编码UI测试与“真实”代码分开。

来源

2013-06-27 07:17:47 Micha

单独编码的UI测试项目+解决方案就是我现在正在使用的。似乎是没有由测试运行器（我不想要）运行CUIT测试的唯一方法，但我不喜欢它，因为它意味着编辑主项目解决方案的人可能仍然不知道CUIT测试存在。 –

也许这“帮助”您的测试亚军“问题”：http://stackoverflow.com/questions/12582025/how-to-exclude-tests-from-vs2012-test-runner – Micha

这就是为什么我试图这条路线现在。我更喜欢所有在一个souluition中，但希望测试跑步者只发现单元测试不CUITs，到目前为止，这看起来像唯一的选择。 –

使用CodedUI测试测试WPF应用程序，编码的ui测试项目应共享解决方案吗？

更新

回答

相关问题