Dove devono essere memorizzati i test di integrazione quando si utilizza il plugin maven-failsafe?

Question

Devo inserire i miei test di integrazione sotto src/test con il resto dei miei test unitari e distinguerli semplicemente con uno schema come *Integr*Test, *ITTest oppure possono essere in src/it (come nel caso dello sviluppo di plug-in Maven e utilizzo del maven-invoker-plugin)?

Lo chiedo perché, per me, non sembra abbastanza pulito se i test di unità e di integrazione sono nello stesso posto (anche se dovessero essere controllati tramite un profilo Maven).

Answer 1

Primo Maven-Fail-Plug viene eseguito di default in un'altra fase del ciclo di vita (test di integrazione) come fa maven-surefire-plugin (test). Inoltre è possibile configurare il plugin maven-failsafe per eseguire l'obiettivo verify nella fase di test post-integration-test se si desidera verificare se i test di integrazione hanno avuto esito negativo. Questo può essere configurato liberamente.

C'è una domanda che mi viene in mente. Hai 10 moduli e ora ti piacerebbe avere test di integrazione? A quale modulo appartengono? Quindi è meglio avere un modulo separato perché non appartengono a nessuno dei 10 moduli.

A parte questo, il plug-in maven-surefire è già configurato nel ciclo di vita predefinito. Sì, un obiettivo supplementare sarebbe un'idea, ma confonderebbe l'utente a utilizzare gli stessi plugin in relazioni diverse. Quindi la separazione delle preoccupazioni è importante qui. A parte le intere configurazioni di default ... Quei plugin condividono una base di codice più grande, ma ci sono differenze ...

Anche ciò che è già stato menzionato da Tunaki è pre-integration-test, per le cose di impostazione come i server ecc integration-test e cose del genere chiudendo giù servizi/server nella fase post-integration-test. Questo non succederà mai nei test unitari.

L'utilizzo di un modulo separato semplifica in genere la configurazione dell'IT, il che significa avere dipendenze diverse (classpath) rispetto ai test dell'unità. Ad esempio cose come Arquillian.org che non vengono mai utilizzate nei test unitari. Questo non può essere gestito in un singolo modulo ... anche qui va bene la separazione dei problemi ..

Inoltre i test di integrazione non possono essere parallati di default mentre i test di unità possono essere per definizione altrimenti non test di unità.

Quindi, per quanto riguarda il layout delle cartelle? Nel modulo di test di integrazione puoi semplicemente utilizzare la cartella src/test/java, il che significa che non hai bisogno di configurazioni supplementari ecc. (Ad esempio tramite build-helper-maven-plugin ecc.) Che rende più semplice e segue più la convenzione sul paradigma di configurazione.

e non dimenticare si può controllare meglio ciò che è in esecuzione nella vostra build (CI) ..

E un altro importante suggerimento. Solitamente i test di integrazione sono spesso correlati all'infrastruttura, quindi a volte può essere utile ignorare i guasti che possono semplicemente gestire utilizzando l'obiettivo check del plugin maven-failsafe ....

Un esempio per un modulo IT può essere trovato here.

Answer 2

Avete ragione che src/it è destinato a essere utilizzato per il test di integrazioni di plug-in. Questo è menzionato nel Standard Directory Layout.

Il maven-failsafe-plugin, per impostazione predefinita, cercherà i test di integrazione all'interno ${project.build.testSourceDirectory}, which is the same come maven-surefire-plugin per i test unitari. Per impostazione predefinita, questo corrisponde a src/test/java. I test di integrazione sono distinti seguendo una naming convention:

<includes> 
    <include>**/IT*.java</include> 
    <include>**/*IT.java</include> 
    <include>**/*ITCase.java</include> 
</includes> 

che è diverso dal naming convention per unità di test:

<includes> 
    <include>**/Test*.java</include> 
    <include>**/*Test.java</include> 
    <include>**/*TestCase.java</include> 
</includes> 

Così mentre avrebbero risiedere nella cartella stessa fonte (src/test/java), la differenza nei nomi li distingue chiaramente. Inoltre, questa è l'impostazione predefinita, quindi non è necessaria alcuna configurazione aggiuntiva.

Detto questo, si può avere altre opzioni:

• Posizionare i test di integrazione all'interno di una cartella di origine diversa. Ciò richiederà alcune configurazioni per farlo funzionare: sarà necessario utilizzare l'obiettivo build-helper-maven-plugin:add-test-source per aggiungere la cartella personalizzata come cartella di origine del test.
• Utilizzare un modulo diverso (se si dispone di un progetto Maven multi-modulo) che conterrà solo i test di integrazione.