Primero un poco de contexto; estamos desarrollando una aplicación WPF de escritorio grande en .NET 4.5 dirigida a Windows 7 y 8 bits. Estamos usando Visual Studio 2012.2 (¡pronto será .3 luego probablemente 2013!) y TFS 2012 (nuevamente .2 pronto será .3 luego 2013).

Actualmente, este producto se encuentra en una única solución grande (algo más de 50 proyectos) que produce un archivo WPF, una carga de archivos DLL y un buen MSI para instalarlo.

Usamos TFS (cerrado y programado) para construir la solución, su instalador (WiX) y ejecutar sus pruebas (SpecFlow para pruebas de unidades BDD y MSTest) y esto está funcionando muy bien.

Tengo una compilación TFS programada por separado que implementa el MSI a la plataforma de prueba física en un dominio de AD no confiable a través de un script de PowerShell (verLos scripts de implementación de la plantilla LabDefault.11 de TFS2012 fallan con "Team Foundation Server no pudo completar la tarea de implementación" para detalles de los desafíos involucrados con eso!)

De acuerdo, ahí es donde estoy, ahora quiero llevar las cosas al siguiente paso; Pruebas CodedUI para conducir la prueba completa de integración de aplicaciones; Quiero "Smoke Test" mis compilaciones.

Así que siendo un alma simple, agregué un nuevo proyecto a mi solución de productos; un proyecto de prueba CodedUI.

Felizmente ejecuta el producto instalado localmente (en lugar del que acaba de construirse; ya que, en última instancia, quiero que el CUIT se ejecute en un banco de pruebas implementado como prueba de humo, y ese equipo acaba de instalar el MSI que acabo de construir) y realiza algunas IU. Pruebas con aseveraciones.

AhoraMi problema es con el proyecto CUIT como parte de la solución de productos que una ejecución de prueba local encuentra y ejecuta mis pruebas CUIT, y esto no es deseado. Solo quiero ejecutar las pruebas CUIT en una fase de prueba de compilaciones de laboratorio.

Asi que¿Es una mala idea poner el proyecto CUIT en la solución del producto? odebe ser una solución separada? Dividirlos parece incorrecto de alguna manera, ya que están relacionados; El proyecto CUIT es la prueba de integración de pila completa para la aplicación desplegable de la solución.

¿Puedo incluir el CUIT en la solución de productos y evitar que el corredor de pruebas vea las pruebas? ¿O es mejor simplemente tener dos soluciones?

¿Cuáles son las ventajas y desventajas de la gente?

Actualizar

Al final, creamos una nueva solución que contiene un proyecto de prueba de IU codificado y nos aseguramos de que se construyó con la misma compilación TFS que creó la solución de UI. Esto nos permite cargar y ejecutar las pruebas de IU codificadas localmente sin problemas, las pruebas de unidad en el proyecto de IU principal se dejan sin analizar. Todavía parece un poco incómodo, pero en un equipo de varias personas por usuario, las configuraciones de prueba eran demasiado incómodas, ya que la división de la IU codificada en una solución diferente era más simple.