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.

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

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

Prerequisiti

  1. I test in Cloud Manager sono eseguiti utilizzando un utente amministratore tecnico.
NOTA
Per eseguire i test funzionali dal computer locale, crea un utente con autorizzazioni di tipo amministratore per ottenere lo stesso comportamento.
  1. L'infrastruttura a contenitori per il test funzionale è limitata dai seguenti vincoli:
Tipo
Valore
Descrizione
CPU
0.5
Quantità di tempo CPU riservato per ogni esecuzione di test
Memoria
0,5 Gi
Quantità di memoria allocata al test, valore in gibibyte.
Timeout
30 min
Il limite di tempo dopo il quale il test viene interrotto.
Durata consigliata
15 min
L’Adobe consiglia di non richiedere più tempo per la scrittura dei test.
NOTA
Se hai bisogno di più risorse, crea un caso per l’Assistenza clienti e descrivi il tuo caso d’uso. Il team di Adobe esamina la tua richiesta e fornisce assistenza adeguata.

Dipendenze

  • aem-cloud-testing-client:

Le modifiche imminenti all'infrastruttura containerizzata per l'esecuzione dei test funzionali richiedono l'aggiornamento della libreria aem-cloud-testing-clients nei test funzionali personalizzati alla versione 1.2.1 o successiva. Verificare che la dipendenza nel file it.tests/pom.xml sia aggiornata di conseguenza.

<dependency>
   <groupId>com.adobe.cq</groupId>
   <artifactId>aem-cloud-testing-clients</artifactId>
   <version>1.2.1</version>
</dependency>
NOTA
Questa modifica deve essere eseguita prima del 6 aprile 2024.
Se non si aggiorna la libreria di dipendenze, possono verificarsi errori di pipeline nel passaggio "Test funzionali personalizzato".