Test funzionali Java™

Ultimo aggiornamento: 9 ottobre 2024
  • Si applica a:
  • Experience Manager as a Cloud Service

Creato per:

  • Amministratore
  • Sviluppatore

Scopri come scrivere test funzionali Java™ per AEM as a Cloud Service

Guida introduttiva ai test funzionali

Al momento della creazione di un nuovo archivio di codice in Cloud Manager, una cartella it.tests viene creata automaticamente con esempi di test.

NOTE
Se l’archivio è stato creato prima della creazione automatica delle cartelle it.tests di Cloud Manager, puoi anche generare la versione più recente utilizzando l’archetipo di progetto AEM.

Una volta ottenuto il contenuto della cartella it.tests, puoi utilizzarla come base per i test e quindi:

  1. Sviluppa i test case.
  2. Eseguire i test localmente.
  3. Salvare il codice nell’archivio di Cloud Manager ed eseguire una pipeline di Cloud Manager.

Scrittura di test funzionali personalizzati

Per scrivere test funzionali personalizzati è possibile utilizzare gli stessi strumenti impiegati da Adobe per la scrittura dei test funzionali del prodotto. Per la scrittura dei test, puoi consultare i test funzionali del prodotto in GitHub come esempio.

Il codice per i test funzionali personalizzati è il codice Java incluso nella cartella it.tests del progetto. Deve produrre un unico JAR con tutti i test funzionali. Se la generazione produce più di un JAR di test, quello selezionato non è deterministico. Se non viene prodotto alcun JAR di test, il passaggio di test viene superato per impostazione predefinita. Per i test di esempio, consulta Archetipo progetto AEM.

I test vengono eseguiti su un’infrastruttura di test gestita da Adobe, che prevede almeno due istanze di authoring, due istanze di pubblicazione e una configurazione del Dispatcher. Questa configurazione significa che i test funzionali personalizzati vengono eseguiti sull’intero stack di AEM.

Struttura dei test funzionali

I test funzionali personalizzati devono essere inclusi come file JAR separati prodotti dalla stessa build Maven degli artefatti da distribuire in AEM. Generalmente, questa build è di un modulo Maven separato. Il file JAR risultante deve contenere tutte le dipendenze richieste e generalmente viene creato con il maven-assembly-plugin utilizzando il descrittore jar-with-dependencies.

Inoltre, l’intestazione del manifesto Cloud-Manager-TestType del file JAR deve essere impostata su integration-test.

Di seguito è riportata una configurazione di esempio per maven-assembly-plugin.

<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

All’interno di questo file JAR, i nomi delle classi dei test effettivi da eseguire devono terminare con IT.

Ad esempio, una classe denominata com.myco.tests.aem.it.ExampleIT verrebbe eseguita, mentre una denominata com.myco.tests.aem.it.ExampleTest no.

Inoltre, per escludere il codice di test dal controllo di copertura dell’analisi del codice, il codice di test deve trovarsi all’interno di un pacchetto denominato it (il filtro di esclusione della copertura è **/it/**/*.java).

Le classi di test devono essere normali test JUnit. L’infrastruttura di test è progettata e configurata per la compatibilità con le convenzioni utilizzate dalla libreria di test aem-testing-clients. Si consiglia ai team di sviluppo di utilizzare questa libreria e seguire le relative best practice.

Per ulteriori dettagli, consulta l’aem-testing-clientsarchivio GitHub.

TIP
Guarda questo video per scoprire come utilizzare i test funzionali personalizzati per acquisire maggiore dimestichezza con le pipeline CI/CD.