Spring Framework 5.0 introdujo soporte básico para ejecutar pruebas en paralelo dentro de la misma JVM cuando se usa Spring TestContext Framework. En general, esto significa que la mayoría de las clases o métodos de prueba se pueden ejecutar en paralelo sin ningún cambio en el código de prueba o la configuración.
Recuerde que introducir paralelismo en un conjunto de pruebas puede provocar efectos secundarios inesperados, lógica inusual durante la ejecución del programa y puede provocar que las pruebas fallen de forma intermitente o aleatoria. Por lo tanto, Spring Team ofrece las siguientes pautas generales con respecto a los casos en los que las pruebas no deben ejecutarse en paralelo.
No ejecute pruebas en paralelo si las pruebas:
-
Utiliza el soporte de anotación
@DirtiesContexten Spring Framework. -
Utilice el soporte de anotación
@MockBeano@SpyBeande Spring Boot. -
Utilice la compatibilidad con la anotación
@FixMethodOrderen JUnit 4, o cualquier característica del marco de prueba diseñada para garantizar que los métodos de prueba se ejecuten en un orden específico. Sin embargo, tenga en cuenta que esto no se aplica cuando se ejecutan clases de prueba completas en paralelo. -
Cambiar el estado de servicios o sistemas compartidos, como la base de datos, el intermediario de mensajes, el sistema de archivos y otros. Esto se aplica tanto a sistemas integrados como externos.
Si la ejecución de una prueba paralela falla con una excepción que indica que ApplicationContext para la prueba actual ya no está activo, esto generalmente significa que ApplicationContext se ha eliminado de la ContextCache en otro hilo.
Esto puede deberse al uso de la anotación @DirtiesContext o al desalojo automático de ContextCache. Si el culpable es la anotación @DirtiesContext, entonces necesita encontrar una manera de evitar el uso de @DirtiesContext o excluir dichas pruebas de la ejecución paralela. Si se ha excedido el tamaño máximo de ContextCache, puede aumentar el tamaño máximo de caché. Para obtener más detalles, consulte la descripción en la sección sobre almacenamiento en caché de contexto.
TestContext subyacente proporciona un constructor de copia como se describe en el javadoc para
TestContext. El
DefaultTestContext utilizado en Spring proporciona dicho constructor. Sin embargo, si está utilizando una biblioteca de terceros que proporciona una implementación
TestContext personalizada, deberá asegurarse de que sea adecuada para ejecutar pruebas en paralelo.
GO TO FULL VERSION