1. Inicio
  2. Pregunta y respuesta
  3. Ejecutando pruebas nUnit de forma multiproceso

Ejecutando pruebas nUnit de forma multiproceso

2009-10-08 22 views
11

¿Es posible ejecutar pruebas de nunidad de manera multiproceso? ¿Hay algún corredor que pueda proporcionar esto?Ejecutando pruebas nUnit de forma multiproceso

Antes de que alguien salto en el concepto de "prueba de unidad", Me explico: Estos son no unidad de prueba estamos utilizando nunit para las pruebas funcionales/integración, así, y algunas de esas pruebas son increíblemente lento, tiene un montón de espera estado. Por lo tanto, el multihilo puede ayudarlos masivamente.

Sé como último recurso que puedo hacer mi propio multi-threading dentro de las pruebas, pero eso introducirá una sobrecarga no requerida.

Fuente

2009-10-08 dr. evil

+1

1 para explicar el escenario :) –

+0

como stackoverflower experimentado Sé lo que hay va a suceder cuando pregunte algo como esto: D –

Respuesta

0

Es posible que desee echar un vistazo a la estructura de prueba multiproceso Overshore que tiene una clase ThreadManager que siempre podría ampliar ligeramente para agregar el concepto de pruebas "fallidas".

http://weblogs.asp.net/rosherove/archive/2007/06/22/multi-threaded-unit-tests-with-osherove-threadtester.aspx

Si sólo está utilizando afirma, puede contar las excepciones.

Buena suerte

PS: ¿por qué no se ejecutan varias Nant/nunit-corredor de proceso?

Fuente

2009-10-08 09:03:11

+0

Sí, lo he visto, pero ese código no es diferente de solo ejecutar subprocesos en su grupo de subprocesos (o me falta algo). No es algo inteligente como [Prueba de Hilo] - ahora sería genial :) En realidad, ejecutar varias instancias de nUnit no es una mala idea, solo un poco desordenado y requiere bastante trabajo manual. –

0

Estoy trabajando en un puerto NET del MultithreadedTC Java library. Mi puerto se llama Ticking Test, y el código fuente se publica en GitHub.

TickingTest no fue pensado originalmente para hacer lo que está intentando, pero podría funcionar. Le permite escribir una clase de prueba con varios métodos marcados con un atributo TestThread. Cada hilo puede esperar a que llegue un cierto conteo de ticks, o afirmar lo que cree que debería ser el conteo de ticks actual. Cuando todos los subprocesos actuales están bloqueados, un subproceso de coordinador avanza el recuento de ticks y se activa cualquier subproceso que esté esperando el siguiente conteo de ticks. Si está interesado, consulte el MultithreadedTC overview para ver ejemplos. MultithreadedTC fue escrito por algunas de las mismas personas que escribieron FindBugs.

He utilizado mi puerto con éxito en un proyecto pequeño. La principal característica que falta es que no tengo forma de seguir los temas recién creados durante la prueba.

Fuente

2009-10-10 00:23:57

2

Pero por supuesto que tiene que tener el apoyo TeamCity para esto también ;-)

Supuestamente NUnit3 tendrá soporte multihilo.

Fuente

2010-11-01 18:17:52 Squirrel

0

No puedo creer que MSTest no aparezca en la lista. Visual Studio ha sido compatible con múltiples pruebas concurrentes por edades.

Fuente

2012-05-07 05:53:15

+0

MSTest la herramienta de prueba de la unidad? Creo que puede estar refiriéndose a las herramientas de prueba de Performance Load que solo están disponibles en la edición Visual Studio Ultimate. NUnit ha probado pruebas concurrentes por un tiempo, pero el autor está buscando realizar pruebas de integración y necesita algo más que un simple corredor de prueba. –

0

hemos creado un script de MSBuild recursiva para ejecutar los archivos DLL de prueba unidad de forma simultánea, lo que se ve algo como esto:

<Target Name="UnitTestDll"> 
    <Message Text="Testing $(NUnitFile)" /> 
    <ItemGroup> 
     <ThisDll Include="$(NUnitFile)"/> 
    </ItemGroup> 
    <NUnit ToolPath="$(NUnitFolder)" Assemblies="@(ThisDll)" OutputXmlFile="$(TestResultsDir)\%(ThisDll.FileName)-test-results.xml" ExcludeCategory="Integration,IntegrationTest,IntegrationsTest,IntegrationTests,IntegrationsTests,Integration Test,Integration Tests,Integrations Tests,Approval Tests" ContinueOnError="true" /> 
    </Target> 

    <Target Name="UnitTest" DependsOnTargets="Clean;CompileAndPackage"> 
     <Message Text="Run all tests in Solution $(SolutionFileName)" /> 
     <CreateItem Include="$(SolutionFolder)**\bin\$(configuration)\**\*.Tests.dll" Exclude="$(SolutionFolder)\NuGet**;$(SolutionFolder)**\obj\**\*.Tests.dll;$(SolutionFolder)**\pnunit.tests.dll"> 
     <Output TaskParameter="Include" ItemName="NUnitFiles" /> 
     </CreateItem> 
    <ItemGroup> 
     <TempProjects Include="$(MSBuildProjectFile)"> 
     <Properties>NUnitFile=%(NUnitFiles.Identity)</Properties> 
     </TempProjects> 
    </ItemGroup> 
    <RemoveDir Directories="$(TestResultsDir)" Condition = "Exists('$(TestResultsDir)')"/> 
    <MakeDir Directories="$(TestResultsDir)"/> 

    <MSBuild Projects="@(TempProjects)" BuildInParallel="true" Targets="UnitTestDll" /> 
    </Target>

Es obvio que todavía tienen sus objetivos de compilación (o en nuestro caso CompileAndPackage) para construir realmente el prueba dlls primero.

Esto también puede confundir los resultados NUnit para la mayoría de las herramientas de informes, pero tras haber tocado ese problema ya escribimos una herramienta para ayudar con eso: https://github.com/15below/NUnitMerger

Fuente

2012-08-02 09:08:36 mavnn

Cuestiones relacionadas

 Cuestiones relacionadas