Quiero excluir algunas pruebas de mi compilación de integración continua, pero no he encontrado una manera de hacerlo.Excepto pruebas de tfs build
Una de las cosas que he intentado fue configurar la prioridad de esas pruebas en -2 y luego en la compilación especifiqué la Prioridad mínima de prueba = -1 pero todavía ejecuta esas pruebas.
Cualquier ayuda sería muy apreciada.
En lugar de utilizar "Listas de prueba" que se han descrito, debe usar el método "Categoría de prueba". Las listas de prueba & La funcionalidad VSMDI ha quedado en desuso en Visual Studio 2010 y Microsoft puede eliminar la característica por completo en una versión futura de Visual Studio.
Si desea alguna información más sobre cómo utilizar categorías de prueba sobre todo con su proceso de construcción automatizado, echa un vistazo a esta entrada del blog: http://www.edsquared.com/2009/09/25/Test+Categories+And+Running+A+Subset+Of+Tests+In+Team+Foundation+Server+2010.aspx
También puede excluir categorías de prueba se ejecute mediante la especificación de la ! (exclamación señalar) carácter delante del nombre de la categoría para definir mejor su filtro.
En mi compilación de CI, me estoy ejecutando con "! Integration &! Load" – felickz
Si está utilizando MSTest puede crear un Test List para las pruebas que necesita en su integración continua.
No sabía acerca de esta característica. Abre un nuevo mundo de posibilidades. ¡Gracias! – Yag
para una configuración de compilación de samle sobre cómo hacer esto con las compilaciones de equipos de TFS 2008, consulte mi publicación a continuación. Para TFS 2010, la definición de compilación se basa en el flujo de trabajo, pero el principio es el mismo allí. – eFloh
FYI - el enfoque de "Lista de prueba" (usando .VSMDI) ha quedado en desuso y no se sugiere su uso por más tiempo. En su lugar, debe usar la función de Categorías de prueba para MSTest. Microsoft puede eliminar por completo la funcionalidad de la lista de prueba en una versión futura de Visual Studio. Tengo más información disponible aquí si está interesado: http://www.edsquared.com/2009/09/25/Test+Categories+And+Running+A+Subset+Of+Tests+In+Team+Foundation+ Server + 2010.aspx –
Mi preferencia sería la anterior utilizando una Lista de prueba, pero algunas personas han emitido la fusión/edición de los archivos vsmdi ... Terminamos con soluciones separadas y usamos una coincidencia de patrón para ejecutar todas las pruebas en la DLL correspondiente.
Con MSTest, puede simplemente crear dos proyectos de prueba (ensamblados) y solo especificar uno en la configuración de compilación para usarlo para la prueba. En MSBuild, este era el camino a seguir. Para las nuevas definiciones de construcción basada en WF, que actualmente no tengo una muestra que nos ocupa:
<ItemGroup>
<!-- TEST ARGUMENTS
If the RunTest property is set to true then the following test arguments will be used to run
tests. Tests can be run by specifying one or more test lists and/or one or more test containers.
To run tests using test lists, add MetaDataFile items and associated TestLists here. Paths can
be server paths or local paths, but server paths relative to the location of this file are highly
recommended:
<MetaDataFile Include="$(BuildProjectFolderPath)/HelloWorld/HelloWorld.vsmdi">
<TestList>BVT1;BVT2</TestList>
</MetaDataFile>
To run tests using test containers, add TestContainer items here:
<TestContainer Include="$(OutDir)\AutomatedBuildTests.dll" />
<TestContainer Include="$(SolutionRoot)\TestProject\WebTest1.webtest" />
<TestContainer Include="$(SolutionRoot)\TestProject\LoadTest1.loadtest" />
Use %2a instead of * and %3f instead of ? to prevent expansion before test assemblies are built
-->
</ItemGroup>
<PropertyGroup>
<RunConfigFile>$(SolutionRoot)\LocalTestRun.testrunconfig</RunConfigFile>
</PropertyGroup>
Consejo: Para utilizar una definición genérica de construcción, nombramos todos nuestros proyectos de prueba "AutomatedBuildTests", es decir, no hay diferencia de solución. Por lo tanto, la definición de compilación se puede incluir en cualquier definición de construcción existente (o incluso ser una común) que siempre ejecuta el conjunto correcto de pruebas. Sería una tarea fácil anteponer una verificación "si existe" para permitir que una definición de compilación ejecute solo pruebas cuando hay un ensamblaje de prueba presente. No usamos esto para obtener errores de compilación cuando no se encuentra ningún ensamblaje de prueba, ya que queremos pruebas con todas las compilaciones que usan esta definición.
En Visual Studio 2012 y versiones posteriores puede configurar su definición de compilación utilizando la configuración Test case filter.
Esta configuración es parte de la definición de su compilación. Abra la definición de compilación y vaya a la pestaña Process. En la sección 3. Test puede definir varias fuentes de prueba. Para cada fuente de prueba, puede especificar un Test case filter.
Puede encontrar los detalles en este artículo de MSDN: Running selective unit tests in VS 2012 RC using TestCaseFilter
he copiado los operadores compatibles y algunos ejemplos de este artículo:
operadores compatibles en RC son:
1. = (es igual)
2.!= (No iguales)
3. ~ (o subcadena contiene sólo para valores de cadena)
4. & (e)
5. | (O)
6.() (un paréntesis para agrupar)
expresssion puede ser creado usando estos operadores como cualquier condición lógica válida. & (y) tiene una prioridad superior a | (o) al evaluar la expresión.
E.g.
"TestCategory = NAR | prioridad = 1" "! Propietario = Vikram & TestCategory = UI" "FullyQualifiedName ~ NameSpace.Class"
"(TestCategory = UI & (Prioridad = 1 |! Prioridad = 2)) | (TestCategory = UI & prioridad = 1)"
Otra posibilidad sería tener algunas fuentes de prueba en una definición de build en algunos (es decir, más o menos) las fuentes de prueba en otras definiciones de compilación.
¿Qué es su Tester? MSTest, NUnit, algo más (?) – pantelif