Domanda

Attualmente sto lavorando a un progetto Java utilizzando Maven.Utilizziamo il plug-in Maven Surefire per eseguire la nostra suite junit come parte del processo di creazione.

La nostra suite di test è in rapida crescita, sia in termini di copertura che di tempi di esecuzione.Il tempo di esecuzione è molto frustrante e richiede molto tempo quando si aspettano dieci minuti per scoprire che un test non è riuscito nel primo minuto di test.

Vorrei trovare un modo per far fallire il processo di compilazione al primo errore/fallimento nella suite di test.So che questo è possibile per altri strumenti di creazione, ma non sono riuscito a trovare un modo per farlo con Maven Surefire.

So che c'è un ticket irrisolto per questa funzionalità nella jira infallibile, ma spero che esista una soluzione esistente per questo.

È stato utile?

Soluzione

A partire dal 6 settembre 2015 sembra che ci sia , -Dsurefire.skipAfterFailureCount=1.

A partire dal 19 ottobre 2015 versione 2.19 è stata rilasciata .

Altri suggerimenti

Per quanto ne so, non , e questo in realtà richiede la risoluzione di SUREFIRE-580 . Se si vuole fare questo accadere più velocemente, si dovrebbe almeno voto per il rilascio e, facoltativamente, inviare una patch;)

Potrebbe esserci un adatto soluzione alternativa, ma dipende dalle tue esigenze ed è necessario utilizzare un server CI in grado di gestire i codici di ritorno del processo jvm.

L'idea di base è interrompere del tutto il processo JVM di Maven e far sapere al sistema operativo che il processo si è interrotto inaspettatamente.Quindi, un server di integrazione continua come Jenkins/Hudson dovrebbe essere in grado di verificare la presenza di un codice di uscita diverso da zero e farti sapere che un test non è riuscito.

Il primo passo è assicurarsi che l'uscita dalla JVM sia sicura al primo fallimento del test.Puoi farlo con JUnit 4.7 o successiva utilizzando un file custom RunListener (mettilo in 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);
        }
}

Quindi, devi configurare quella classe in modo che surefire la registrerà con JUnit 4 Runner.Modifica il tuo pom.xml e aggiungi il listener proprietà di configurazione al plug-in maven-surefire.Ne avrai bisogno anche tu configurare surefire per non eseguire il fork di un nuovo processo JVM per l'esecuzione delle prove.Altrimenti si andrà avanti con i prossimi test case.

<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>

Se questo non aiuta, proverei a creare un fork del plugin Maven SureFire Junit Provider.

A proposito, i test unitari, per definizione, dovrebbero essere eseguiti più velocemente di 0,1 secondi.Se la tua build impiega davvero così tanto tempo a causa dei test unitari, dovrai farli funzionare più velocemente in futuro.

È possibile eseguire maven opzione --fail-fast con:

  

L'opzione -ff è molto utile per gli sviluppatori che eseguono interattivo   build che vogliono avere un feedback rapido durante il ciclo di sviluppo.

Un esempio può essere:

mvn clean test -ff

http://books.sonatype.com/mvnref -book / di riferimento / corsa-setta-options.html

A pochi modi per accelerarlo se non è esattamente quello che vi serve:

Questa non è una risposta diretta alla domanda, ma può anche essere utile per alimentare la produzione di Maven attraverso grep, per togliere più cose e vi aiuterà a vedere dove i fallimenti dei test sono.

In questo modo:

mvn test | grep -w 'Running\|Tests'

Il che produce un output (per il mio codice) in questo modo:

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

Molto più facile da vedere dove il primo errore del fallimento è.

Questo non risolve il problema esattamente, ma la soluzione che il mio posto di lavoro in ultima analisi, si avvicinò con era di usare Clover di Atlassian per eseguire specializzata costruisce di appena prove relative alle codice modificato.

Abbiamo una build del trifoglio che esegue i test per il codice modificato e, a sua volta prende il via la piena test build.

Questo ha dimostrato di essere una soluzione soddisfacente.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top