tdd - ¿Cómo le digo a MSTEST que ejecute todos los proyectos de prueba en una Solución?

cruisecontrol.net command-prompt

Question

Necesito saber cómo decirle a MSTEST que ejecute todos los proyectos de prueba en un archivo de solución. Esto debe hacerse desde la línea de comandos. En este momento tengo que pasarle un archivo de proyecto específico, estoy tratando de que se ejecute desde un archivo SOLUCIÓN.

Espero que esto sea posible, porque en Visual Studio, al presionar Ctrl + R, A, se ejecutan TODAS las pruebas en la solución abierta actualmente.

La forma en que he interpretado los archivos de ayuda, tiene que pasar en cada DLL específicamente.

Quiero ejecutar esto desde la línea de comandos desde mi servidor CruiseControl.NET, para poder escribir otras utilidades para que esto suceda. Si hay una forma extraña de hacer que esto suceda a través de algún otro método, hágamelo saber.

¿Cómo le digo a MSTEST que ejecute todos los proyectos de prueba para una solución?

<exec>
<!--MSTEST seems to want me to specify the projects to test -->
<!--I should be able to tell it a SOLUTION to test!-->
<executable>mstest.exe</executable>
<baseDirectory>C:/projects/mysolution/</baseDirectory>
<buildArgs>/testcontainer:testproject1/bin/release/TestProject1.dll
/runconfig:localtestrun.Testrunconfig
/resultsfile:C:/Results/testproject1.results.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>

Answer 1

¿Por qué no hacer que msbuild genere todos los ensamblajes de prueba en una carpeta?

Intente configurar las propiedades OutputPath, OutputDir, OutDir en msbuild para lograr esto.

luego haga que mstest se ejecute en todos los ensamblajes de esa carpeta.

Answer 2

Acabo de resolver este problema recientemente. Aquí está mi propuesta: usar testmetadata + testlist opción de mstest

1. Primero debes crear una lista de prueba en el archivo testmetadata (vsmdi)
2. la línea de comandos debe ser mstest /testmetadata:....vsmdi /testlist:<name>
3. Luego usa ccnet config para ejecutar mstest

Answer 3

Este es un hilo viejo, pero he estado luchando con el mismo problema y me di cuenta de que realmente puedes ejecutar MSTest en cada DLL en la solución completa y realmente no causa ningún problema. MSTest está buscando métodos en los ensamblajes marcados con el atributo [Método de prueba], y los ensamblajes que no son ensamblajes "de prueba" simplemente no tendrán ningún método decorado con ese atributo. Así que obtienes un "No hay pruebas para ejecutar". mensaje de vuelta y ningún daño hecho.

Así, por ejemplo, en NAnt puedes hacer esto:

<target name="default">
<foreach item="File" property="filename">
<in>
<items>
<include name="**/bin/Release/*.dll" />
</items>
</in>
<do>
<echo message="${filename}" />
<exec program="C:/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/MSTest.exe">
<arg value="/testcontainer: ${filename}" />
<arg value="/nologo" />
</exec>
</do>
</foreach>
</target>

y ejecutará todos los métodos de prueba en cada dll en cada carpeta bin / Release en la solución. Aquellos que no sean dlls de prueba devolverán un "No hay pruebas para ejecutar". y aquellos que tienen pruebas tendrán las pruebas ejecutadas. La única parte que aún no he descubierto es que (en NAnt) la ejecución se detiene la primera vez que un comando devuelve un valor distinto de cero. Entonces, si alguna de las pruebas unitarias falla, no se va a ejecutar ninguna prueba en los ensamblajes posteriores. Eso no es genial, pero si todas las pruebas pasan, entonces todas se ejecutarán.

Answer 4

No lo sé directamente, pero aquí es donde VSMDI [fx: spits in a corner] puede ayudar. En su solución agregue todas las pruebas al VSMDI. Y luego pase el VSMDI a mstest usando / testmetadata.

Sin embargo, le sugiero que siga las convenciones anteriores. Y use una convención de nomenclatura y voltee eso del archivo SLN usando, por ejemplo, un bucle for en el script de comando

Answer 5

Para elaborar la respuesta de VladV y hacer las cosas un poco más concretas, seguir la convención de nomenclatura sugerida para ejecutar sus pruebas se puede automatizar fácilmente con MSBuild . El siguiente fragmento del archivo msbuild de mi proyecto actual hace exactamente lo que pidió.

<Target Name="GetTestAssemblies">
<CreateItem
Include="$(WorkingDir)/unittest/**/bin/$(Configuration)/**/*Test*.dll"
AdditionalMetadata="TestContainerPrefix=/testcontainer:">
<Output
TaskParameter="Include"
ItemName="TestAssemblies"/>
</CreateItem>
</Target>
<!-- Unit Test -->
<Target Name="Test" DependsOnTargets="GetTestAssemblies">
<Message Text="Normal Test"/>
<Exec
WorkingDirectory="$(WorkingDir)/unittest"
Command="MsTest.exe @(TestAssemblies->''%(TestContainerPrefix)%(FullPath)'','' '') /noisolation /resultsfile:$(MSTestResultsFile)"/>
<Message Text="Normal Test Done"/>
</Target>

Además, integrar MsBuild con CruiseControl es muy sencillo.

Editar
Aquí le indicamos cómo puede ''llamar'' msbuild desde su ccnet.config.

Primero, si aún no usa MSBuild para la automatización de su compilación, agregue el siguiente xml alrededor del fragmento de código presentado anteriormente:

<Project DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
..... <insert snippet here> .....
</Project>

Guarde esto en, por ejemplo, RunTests.proj junto a su solución en su árbol de fuentes. Ahora puede modificar el bit de ccnet.config anterior a lo siguiente:

<msbuild>
<executable>C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/MSBuild.exe</executable>
<workingDirectory>C:/projects/mysolution/</workingDirectory>
<baseDirectory>C:/projects/mysolution/</baseDirectory>
<projectFile>RunTests.proj</projectFile>
<targets>Test</targets>
<timeout>600</timeout>
<logger>C:/Program Files/CruiseControl.NET/server/ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>

Answer 6

Podría imponer alguna convención sobre el nombre y la ubicación de los proyectos de prueba, luego podría ejecutar MSTest en, digamos, todos * Test.dll debajo de la ubicación de su solución.

Que yo sepa, no hay forma de distinguir un proyecto de prueba de un proyecto DLL ''normal'' basado únicamente en un archivo de solución. Entonces, una alternativa podría ser analizar los archivos del proyecto y / o los archivos .vsmdi para encontrar los proyectos de prueba, pero eso podría ser bastante complicado.

Answer 7

Sé que este hilo es bastante antiguo, pero sigue siendo alto en Google, así que pensé que podría ayudar a uno o dos. De todos modos, ya que no hay una solución satisfactoria para esto. He escrito una tarea msbuild para esto. los detalles se pueden encontrar aquí: http://imistaken.blogspot.com/2010/08/running-all-tests-in-solution.html

Answer 8

Simplemente escribiría un objetivo que lo llame de la manera que usted desea, y luego crearía un archivo por lotes que llame al objetivo que contiene todas las DLL a probar.

A menos que esté agregando proyectos de prueba todo el tiempo, rara vez necesitará modificarlo.