¿Por qué los marcos xUnit no permiten que las pruebas se ejecuten en paralelo?

¿Conoces algún marco de xUnit que permita ejecutar pruebas en paralelo para utilizar múltiples núcleos en la máquina actual?

Si ninguno (o muy pocos) lo hace, tal vez 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 múltiples hilos?

NUnit 2.5 paquete pNUnit que permite la ejecución de pruebas en paralelo.

Esta versión incluye pNUnit, un corredor NUnit extendido para pruebas paralelas distribuidas. El programa pNUnit se desarrolló en Codice Software para su uso en las pruebas de Plastic SCM y se ha contribuido a NUnit. Para obtener más información sobre el uso de pNUnit, consulte el sitio pNUnit.

El lado JUnit tiene paralelo-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 múltiples hilos?

Una gran cantidad de código solo funciona cuando se ejecuta un solo subproceso. Es trivial producir accidentalmente contención de recursos y puntos muertos cuando se escriben programas bajo el supuesto de que se ejecutarán con un solo subproceso. Y esto funciona bien porque la mayoría de los programas realmente funcionan con un solo subproceso. El paralelismo se obtiene al ejecutar múltiples copias o diferentes programas al mismo tiempo (los scripts web son un ejemplo común: muchos usuarios que acceden a una sola página significan muchas copias de los scripts para esa página ejecutándose al mismo tiempo).

Imagine una clase simple de "registro a archivo". Cuando crea una instancia, abre el archivo para escribir, cuando libera 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 ejecuta uno a la vez, todas las pruebas pasarían.

Todo esto puede codificarse, y el simple ejemplo podría modificarse para que funcione. Pero hacer eso probablemente sea innecesario para el programa original . Tener que escribir código seguro para subprocesos solo para poder ejecutar pruebas unitarias no es razonable para muchas personas. Por lo tanto, las pruebas unitarias multiproceso deberían seguir siendo un extra opcional.

Si las pruebas necesitan configurar y consultar una base de datos, las pruebas que se ejecutan en paralelo interferirían entre sí, a menos que haya una base de datos separada para cada prueba que se ejecute en paralelo.

Si bien JUnit per se puede no permitirlo (aunque no estoy íntimamente familiarizado con sus últimas versiones), Maven con su complemento Surefire tiene una opción para ejecutar pruebas en paralelo. Sin embargo, 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é que algunos de los accesorios de prueba tienen dependencias implícitas entre (hemos encontrado algunas de esas dependencias 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 fallen de manera impredecible. Puede 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 problemas más importantes con los que lidiar: el tiempo es un recurso escaso (como de costumbre).

La codificación multiproceso no es trivial. Incluso cuando lo hacen personas que saben lo que están haciendo, pueden ocurrir errores dependientes del tiempo. Son difíciles de arreglar. Habiendo tratado con el que pueden producirse unos pocos miles de errores de tipo multicapa, preferiría no tenerlos en mi marco de prueba. La primera solución que obtuve parecía funcionar, pero en pruebas posteriores se descubrió que se había convertido en un error de uno en decenas de miles.

Las técnicas para realizar subprocesos múltiples en procesadores múltiples están mejorando con la llegada de las PC con múltiples procesadores. Sin embargo, tomará tiempo antes de que se usen ampliamente.

Algunas suites de prueba tienen dependencias entre las pruebas que no necesitan ser declaradas explícitamente cuando las pruebas se ejecutan en una sola secuencia. Sin embargo, en una máquina de vapor múltiple, tendrían que especificarse explícitamente. (Donde tales dependencias deberían existir es una pregunta diferente).

Desde otro punto de vista, algunas cosas simplemente no necesitan ejecutarse en paralelo. Si el proceso se ejecuta adecuadamente rápido, puede ser mejor enfocar los esfuerzos en otras cosas que no sean 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. Lamentablemente, el proyecto ya no está muy vivo.

xUnit 2.0 también debería admitir pruebas de unidades paralelas, pero aún no lo he probado.