maven 2 - reports - ¿Hay alguna manera de "fallar rápido" para junit con el plugin maven surefire?
maven-surefire-plugin pom (7)
Algunas formas de acelerarlo si no es exactamente lo que necesita:
Si se trata de una compilación de varios módulos, agregue --fail-fast a la línea de comando para abandonar después del primer módulo.
Considere la posibilidad de evitar las pruebas de integración de larga ejecución en una fase diferente del ciclo de vida.
Mire en una solución basada en perfiles para pruebas rápidas y lentas: ¿hay alguna forma de saber con certeza si omite las pruebas en un determinado paquete? .
Actualmente estoy trabajando en un proyecto de Java usando maven. Usamos el plugin maven surefire para ejecutar nuestra suite junit como parte del proceso de compilación.
Nuestro conjunto de pruebas está creciendo rápidamente, tanto en tiempo de cobertura como de ejecución. El tiempo de ejecución es muy frustrante y consume mucho tiempo cuando termina esperando diez minutos para descubrir que una prueba falló en el primer minuto de prueba.
Me gustaría encontrar una forma de hacer que el proceso de compilación falle en el primer error / falla en el conjunto de pruebas. Sé que esto es posible para otras herramientas de compilación, pero no he podido encontrar la manera de hacerlo con Mavenfirefire.
Sé que hay un boleto sin resolver para esta funcionalidad en la jira surefire, pero espero que exista una solución existente para esto.
Esta no es una respuesta directa a la pregunta, pero también puede ser útil para alimentar la salida de maven a través de grep, quitar la mayoría de las cosas y ayudarlo a ver dónde están las fallas de la prueba.
Me gusta esto:
mvn test | grep -w ''Running/|Tests''
Que produce resultados (para mi código) como este:
Running scot.mygov.pp.test.dashboard.DashboardJsonSerDesCRUDTest
Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
Running scot.mygov.pp.test.dashboard.DashboardBaselineCRUDTest
Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Running scot.mygov.pp.test.dashboard.DashboardDatabaseValidationTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.264 sec
Running scot.mygov.pp.test.dashboard.DashboardServiceWebServiceIsolationCRUDTest
Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Es mucho más fácil ver dónde está el primer error de falla.
Esto no resuelve la pregunta exactamente, pero la solución que mi lugar de trabajo finalmente propuso fue usar Atlassian''s Clover para ejecutar compilaciones especializadas de pruebas que pertenecen al código modificado.
Tenemos una compilación de Clover que ejecuta las pruebas del código modificado y, a su vez, inicia la compilación de prueba completa.
Esto ha demostrado ser una solución satisfactoria.
Por lo que sé, no , y esto realmente requiere la resolución de SUREFIRE-580 . Si desea que esto suceda más rápido, al menos debería votar por el problema y, opcionalmente, enviar un parche;)
Puede ejecutar maven
con --fail-fast
opción de --fail-fast
:
La opción
-ff
es muy útil para los desarrolladores que ejecutan construcciones interactivas que desean tener una respuesta rápida durante el ciclo de desarrollo.
un ejemplo puede ser:
mvn clean test -ff
http://books.sonatype.com/mvnref-book/reference/running-sect-options.html
Puede haber una solución alternativa adecuada, pero depende de sus requisitos y necesita usar un servidor de CI que pueda manejar los códigos de retorno del proceso de jvm.
La idea básica es detener por completo el proceso JVM de Maven y dejar que el sistema operativo sepa que el proceso se detuvo inesperadamente. Entonces, un servidor de integración continua como Jenkins / Hudson debería poder buscar un código de salida distinto de cero y hacerle saber que una prueba ha fallado.
El primer paso es asegurarse de que el fuego salga de la JVM en la primera falla de prueba. Puede hacerlo con JUnit 4.7 o superior utilizando un RunListener
personalizado (póngalo en src / test / java):
package org.example
import org.junit.runner.notification.Failure;
import org.junit.runner.notification.RunListener;
public class FailFastListener extends RunListener {
public void testFailure(Failure failure) throws Exception {
System.err.println("FAILURE: " + failure);
System.exit(-1);
}
}
Luego, necesita configurar esa clase para que surefire lo registre con el JUnit 4 Runner. Edite su pom.xml
y agregue la propiedad de configuración del listener
al maven-surefire-plugin. También deberá configurar surefire para no bifurcar un nuevo proceso de JVM para ejecutar las pruebas. De lo contrario, continuará con los próximos casos de prueba.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.10</version>
<configuration>
<forkMode>never</forkMode>
<properties>
<property>
<name>listener</name>
<value>org.example.FailFastListener</value>
</property>
</properties>
</configuration>
</plugin>
Si esto no ayuda, trataré de bifurcar el plugin de proveedor junit de maven surefire.
Por cierto, las pruebas unitarias, por definición, deberían correr más rápido que 0.1 segundos. Si su construcción realmente lleva tanto tiempo debido a las pruebas unitarias, tendrá que hacer que corran más rápido en el futuro.
A partir del 6 de septiembre de 2015 , aparece , -Dsurefire.skipAfterFailureCount=1
.
A partir del 19 de octubre de 2015 , se lanzó la versión 2.19 .