首先是一些背景;我们正在开发一个面向64位Windows 7和8的.NET 4.5中的大型桌面WPF应用程序。我们正在使用Visual Studio 2012.2（很快就会是.3，然后可能是2013年！）和TFS 2012（再次.2很快将成为.3然后2013年）。

目前这款产品全部采用单一大型解决方案（仅超过50个项目），产生一个WPF exe，一堆dll和一个不错的MSI来安装它。

我们使用TFS（门控和预定）来构建解决方案，其安装程序（WiX）并运行其测试（SpecFlow for BDD和MSTest单元测试），这非常有用。

我有一个单独的预定TFS构建，它通过PowerShell脚本将MSI部署到不受信任的AD域中的物理测试装备（有关所涉及的挑战的详细信息，请参阅TFS2012 LabDefault.11 template deploy scripts fail with “Team Foundation Server could not complete the deployment task”。）

好的，这就是我的位置，现在我想把事情带到下一步; CodedUI测试推动完整的应用程序集成测试;我想“冒烟测试”我的构建。

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

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

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

所以将CUIT项目置于产品解决方案中是一个坏主意吗？或它应该是一个单独的解决方案吗？由于它们是相关的，因此拆分它们似乎是错误的; CUIT项目是解决方案可部署应用程序的完整堆栈集成测试。

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

有什么优点和缺点？

更新

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