使用CodedUI测试测试WPF应用程序，编码的ui测试项目应该共享解决方案吗？ [英] Testing an WPF app with CodedUI tests, should the coded ui test project share a solution or not?
问题描述
首先是一些上下文；我们正在.NET 4.5中开发一个针对64位Windows 7和8的大型桌面WPF应用程序。我们正在使用Visual Studio 2012.2（不久将是.3，然后可能是2013！）和TFS 2012（再次是.2，然后是.3） 2013）。
当前，该产品全部在一个大型解决方案（仅超过50个项目）中，产生WPF exe，大量的dll和不错的MSI
我们使用TFS（门控和调度）来构建解决方案，其安装程序（WiX）并运行其测试（SpecFlow for BDD和MSTest）
我有一个单独的预定TFS构建，该构建通过MSI将MSI部署到不受信任的AD域中的物理测试台PowerShell脚本（请参阅 TFS2012 LabDefault.11模板部署脚本失败，并显示 Team Foundation Server无法完成部署任务 ，以获取有关
好的，这就是我要去的地方，现在我想将事情进行下一步； CodedUI测试以驱动完整的应用程序集成测试；我想吸烟测试
因此，作为一个简单的灵魂，我在产品解决方案中添加了一个新项目；一个CodedUI测试项目。
这愉快地运行了本地安装的产品（而不是刚刚构建的产品；因为我最终希望CUIT能够在已部署的测试平台上作为烟雾测试运行，并且该钻机刚刚安装了我刚刚构建的MSI），并使用断言执行了一些UI测试。
现在我的问题是CUIT项目作为本地产品解决方案的一部分测试运行查找并运行我的CUIT测试，这是不希望的。我只想在实验室构建测试阶段中运行CUIT测试。
所以将CUIT项目放入产品解决方案不是一个好主意吗？或应该是单独的解决方案吗？拆分它们似乎是错误的，因为它们是相关的。 CUIT项目是针对该解决方案的可部署应用程序的完整堆栈集成测试。
我可以将CUIT包含在产品解决方案中，并阻止测试运行者查看测试吗？还是只有两个解决方案更好？
优缺点是什么？
Update
<最后，我们创建了一个新的解决方案，其中包含一个已编码的UI测试项目，并确保使用与构建该UI解决方案相同的TFS构建来构建该解决方案。这使我们可以在本地加载和运行编码的UI测试，而不会出现问题，主UI项目中的单元测试不受影响。似乎仍然有些脱节，但是在多人团队中，每个用户的测试设置太笨拙了，将编码的UI拆分为其他解决方案更为简单。
我所做的是制作一个解决方案，并在其中创建了CUIT项目，然后在其中进行了多个编码UI测试。这很好，因为使用orderedTest可以将它们一起运行，并且它们还共享一个UIMap，这也有帮助。
First some context; we are developing a large desktop WPF application in .NET 4.5 targeting 64 bit Windows 7 and 8. We are using Visual Studio 2012.2 (soon to be .3 then probably 2013!) and TFS 2012 (again .2 soon to be .3 then 2013).
Currently this product is all in a single large solution (just over 50 projects) yielding a WPF exe, a load of dlls and a nice MSI to install it.
We use TFS (gated and scheduled) to build the solution, its installer (WiX) and run its tests (SpecFlow for BDD and MSTest unit tests) and this is working very well.
I have a separate scheduled TFS build that deploys the MSI to physical test rig in a untrusted AD domain via a PowerShell script (see TFS2012 LabDefault.11 template deploy scripts fail with "Team Foundation Server could not complete the deployment task" for details of the challenges involved with that!)
OK so that's where I am, now I want to take things to the next step; CodedUI tests to drive full app integration test; I want to "Smoke Test" my builds.
So being a simple soul I added a new project to my products solution; a CodedUI test project.
This happily runs the locally installed product (rather then the just built one; as I ultimately want the CUIT to be running on a deployed test rig as a smoke test, and that rig has just installed the MSI I just built) and performs some UI tests with assertions.
Now my problem is with the CUIT project as part of the products solution a local test run finds and runs my CUIT tests, and this is undesired. I only want to run the CUIT tests in a lab builds test phase.
So is putting the CUIT project into the product solution a bad idea? or should it be a separate solution? Splitting them seems wrong somehow as they are related; the CUIT project is the full stack integration test for the solution's deployable application.
Can I include the CUIT in the products solution and stop the test runner seeing the tests? or is it better just to have two solutions?
What are the pros and cons folks?
Update
In the end we created a new solution containing a coded UI test project and ensured this was built with the same TFS build that built the UI solution. This allows us to load and run the coded UI tests locally without issues, the unit tests in the main UI project are left unmolested. Still seems a little disjointed but on a multiple person team per user test settings were too awkward splitting the coded UI into a different solution was simpler.
What I did was make one Solution and made a CUIT project within, I then made multiple Coded UI test's within that. This is good because using an orderedTest you can run them together and they also share a UIMap which helps too.
这篇关于使用CodedUI测试测试WPF应用程序，编码的ui测试项目应该共享解决方案吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
