¿Sabe de algún marco xUnit que permita ejecutar pruebas en paralelo, para hacer uso de múltiples núcleos en la máquina de hoy?
Si ninguno (o tan pocos) de ellos lo hace, quizás haya una razón ... ¿Es que las pruebas suelen ser tan rápidas que las personas simplemente no sienten la necesidad de paralelizarlas?
¿Hay algo más profundo que impida distribuir (al menos algunas de) las pruebas en varios subprocesos?
NUnit 2.5 pNUnit, que permite la ejecución de pruebas en paralelo.
Este lanzamiento incluye pNUnit, un corredor NUnit extendido para distribuido pruebas paralelas. El programa pNUnit era Desarrollado en Codice Software para su uso. en la prueba del plástico SCM y tiene Ha sido contribuido a NUnit. Para más información sobre el uso de pNUnit ver la pNUnit sitio.
El lado JUnit tiene parallel-junit así como amino .
Para responder a la segunda parte de su pregunta: ¿Hay algo más profundo que impida distribuir (al menos algunas de) las pruebas en varios subprocesos?
Una gran cantidad de código solo funciona cuando se ejecuta un solo hilo. Es trivial producir accidentalmente una contención de recursos y puntos muertos cuando se escriben programas en el supuesto de que se ejecutarán en un solo hilo. Y esto funciona bien porque la mayoría de los programas realmente ejecutan un solo hilo. El paralelismo se obtiene al ejecutar varias copias o diferentes programas al mismo tiempo (los scripts web son un ejemplo común: muchos usuarios que acceden a una sola página significa muchas copias de los scripts para esa página que se ejecuta al mismo tiempo).
Imagina una clase simple de "registro a archivo". Cuando creas una instancia, abre el archivo para escribir, y cuando liberas la instancia, cierra el archivo. Entonces, la primera prueba crea una instancia y comienza a ejecutar una prueba. La segunda prueba hace lo mismo en un segundo hilo. Y falla, porque la segunda instancia no puede obtener acceso de escritura al archivo. Pero si se ejecutan de una en una, todas las pruebas pasarán.
Todo esto se puede codificar, y el ejemplo simple podría ser ajustado para que funcione. Pero hacer eso es probablemente innecesario para el programa original . Tener que escribir código seguro para subprocesos para que pueda ejecutar pruebas unitarias no es razonable para muchas personas. Por lo tanto, las pruebas unitarias de subprocesos múltiples deben seguir siendo un extra opcional.
Si las pruebas necesitan configurar y consultar una base de datos, las pruebas que se ejecutan en paralelo interferirán entre sí a menos que haya una base de datos separada para cada prueba en paralelo.
Aunque JUnit per se puede no permitirlo (aunque no estoy muy familiarizado con sus últimas versiones), Maven con su complemento Surefire tiene una opción para ejecutar pruebas en paralelo. Aún no lo he probado.
No estoy muy presionado para investigar esta opción, ya que solo tenemos un poco más de mil pruebas y se ejecutan lo suficientemente rápido. Sin embargo, sí sé que algunos de los dispositivos de prueba tienen dependencias implícitas entre (hemos encontrado algunas dependencias de este tipo cuando algunas pruebas se rompieron inesperadamente en el pasado), por lo que existe el riesgo de que la paralelización de las pruebas haga que algunas de ellas falle de manera impredecible. Puedes decir que esto está bien ya que hace que el problema sea explícito. Sin embargo, estamos lidiando con un sistema heredado y tenemos muchos más problemas importantes con los que lidiar: el tiempo es un recurso escaso (como es habitual).
La codificación de subprocesos múltiples no es trivial. Incluso cuando lo realizan personas que saben lo que están haciendo, pueden ocurrir errores dependientes de la sincronización. Son difíciles de arreglar. Habiendo tratado con el problema de unos pocos miles de errores de tipo de caso que pueden producir las múltiples huellas, preferiría no tenerlos en mi marco de prueba. La primera solución que obtuve pareció funcionar, pero en pruebas posteriores se encontró que se había convertido en uno en decenas de miles de errores.
Las técnicas para realizar subprocesos múltiples en multiprocesadores están mejorando con la llegada de las PC multiprocesador. Sin embargo, tomará tiempo antes de que se utilicen ampliamente.
Algunas suites de prueba tienen dependencias entre las pruebas que no necesitan indicarse explícitamente cuando las pruebas se ejecutan en una sola secuencia. Sin embargo, en un motor de vapor múltiple, tendrían que ser expresados explícitamente. (Donde deben existir tales dependencias es una pregunta diferente).
Desde otro punto de vista, algunas cosas simplemente no necesitan ejecutarse en paralelo. Si el proceso se ejecuta adecuadamente de manera rápida, es mejor enfocar los esfuerzos en otras cosas que no sea la implementación de subprocesos múltiples.
MBUnit puede ejecutar pruebas en paralelo simplemente especificando algunos atributos de nivel de ensamblaje.
[assembly: DegreeOfParallelism(6)]
[assembly: Parallelizable(TestScope.All)]
He estado usando ese proyecto para ejecutar pruebas de selenio en paralelo con bastante éxito durante algún tiempo. Desafortunadamente el proyecto ya no está muy vivo.
xUnit 2.0 también debería admitir pruebas unitarias en paralelo, pero todavía no lo he probado.
Lea otras preguntas en las etiquetas xunit multithreading tests