I test dell'interfaccia utente sono test basati su selenio inclusi in un'immagine Docker per consentire un'ampia scelta in linguaggio e framework (come Java e Maven, Node e WebDriver.io o qualsiasi altro framework e tecnologia basati su Selenium). L'immagine Docker può essere creata con strumenti standard, ma deve rispettare alcune convenzioni durante la sua esecuzione. Quando si esegue l'immagine Docker, viene automaticamente eseguito il provisioning di un server Selenium. Le convenzioni di runtime descritte di seguito consentono al codice di test di accedere sia al server di Selenium che alle istanze di AEM in fase di test.
Per utilizzare i test dell'interfaccia utente come descritto in questa pagina, è necessario aggiornare le pipeline di fase e di produzione create prima del 10 febbraio 2021.
Per informazioni sulla configurazione della tubazione, vedere Configurazione della tubazione CI-CD.
I test dell'interfaccia utente sono generati da un contesto di creazione Docker generato da un progetto Maven. Cloud Manager utilizza il contesto di creazione Docker per generare un'immagine Docker che contiene i test effettivi dell'interfaccia utente. In sintesi, un progetto Maven genera un contesto di creazione Docker e il contesto di creazione Docker descrive come creare un'immagine Docker contenente i test dell'interfaccia utente.
Questa sezione descrive i passaggi necessari per aggiungere un progetto di test dell’interfaccia utente all’archivio. Se hai fretta o non hai requisiti speciali per il linguaggio di programmazione, il AEM Project Archetype può generare un progetto di test dell'interfaccia utente.
Per generare un contesto di creazione Docker, è necessario un modulo Maven che:
Dockerfile
e tutti gli altri file necessari per creare l'immagine Docker con i test.ui-test-docker-context
.Il modo più semplice per ottenere questo è configurare il Maven Assembly Plugin per creare l'archivio contestuale della build Docker e assegnarvi il classificatore giusto.
È possibile creare test dell'interfaccia utente con tecnologie e framework diversi, ma questa sezione presuppone che il progetto sia disposto in modo simile a quello descritto di seguito.
├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│ ├── package.json
│ ├── index.js
│ └── wdio.conf.js
└── wait-for-grid.sh
Il file pom.xml
si occupa della build Maven. Aggiungere un'esecuzione al plug-in dell'assieme Maven simile a quanto segue.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Questa esecuzione indica al plug-in di assemblaggio Maven di creare un archivio basato sulle istruzioni contenute in assembly-ui-test-docker-context.xml
, denominato "descrittore di assembly" nel gergo del plugin. Il descrittore dell'assembly elenca tutti i file che devono far parte dell'archivio.
<assembly>
<id>ui-test-docker-context</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${basedir}</directory>
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
</includes>
</fileSet>
<fileSet>
<directory>${basedir}/test-module</directory>
<excludes>
<exclude>node/**</exclude>
<exclude>node_modules/**</exclude>
<exclude>reports/**</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
Il descrittore dell'assembly indica al plug-in di creare un archivio di tipo .tar.gz
e gli assegna il ui-test-docker-context
classificatore. Inoltre, elenca i file che devono essere inclusi nell'archivio:
Dockerfile
, obbligatorio per la creazione dell'immagine Docker.wait-for-grid.sh
, le cui finalità sono descritte di seguito.test-module
.Il descrittore dell'assembly esclude inoltre alcuni file che potrebbero essere generati durante l'esecuzione localmente dei test dell'interfaccia utente. Questo garantisce un archivio più piccolo e build più veloci.
L'archivio contenente il contesto di creazione Docker viene prelevato automaticamente da Cloud Manager, che genererà l'immagine Docker contenente i test durante le pipeline di distribuzione. Alla fine, Cloud Manager eseguirà l'immagine Docker per eseguire i test dell'interfaccia utente sull'applicazione.
Questa sezione descrive le convenzioni che l'immagine Docker contenente i test dell'interfaccia utente deve seguire. L'immagine Docker è ricavata dal contesto di creazione Docker descritto nella sezione precedente.
Le seguenti variabili di ambiente verranno trasmesse all'immagine Docker in fase di esecuzione.
Variabile | Esempi | Descrizione |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
URL del server selenio |
SELENIUM_BROWSER |
chrome , firefox |
Implementazione del browser utilizzata dal server selenio |
AEM_AUTHOR_URL |
http://my-ip:4502/context-path |
URL dell’istanza di creazione AEM |
AEM_AUTHOR_USERNAME |
admin |
Nome utente per accedere all’istanza di creazione AEM |
AEM_AUTHOR_PASSWORD |
admin |
La password per accedere all'istanza di creazione AEM |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
URL dell’istanza di pubblicazione AEM |
AEM_PUBLISH_USERNAME |
admin |
Il nome utente per accedere all’istanza di pubblicazione AEM |
AEM_PUBLISH_PASSWORD |
admin |
La password per accedere all’istanza di pubblicazione AEM |
REPORTS_PATH |
/usr/src/app/reports |
Percorso in cui salvare il rapporto XML dei risultati del test |
UPLOAD_URL |
http://upload-host:9090/upload |
URL in cui deve essere caricato il file per renderlo accessibile a Selenium |
Prima dell'inizio dei test, è responsabilità dell'immagine Docker assicurarsi che il server Selenium sia attivo e funzionante. L'attesa del servizio Selenium è un processo in due fasi:
SELENIUM_BASE_URL
.Una volta che l'endpoint di stato del selenio risponde con una risposta positiva, i test possono finalmente avviarsi.
L'immagine Docker deve generare rapporti di prova in formato JUnit XML e salvarli nel percorso specificato dalla variabile di ambiente REPORTS_PATH
. Il formato JUnit XML è un formato diffuso per la generazione di rapporti sui risultati dei test. Se l'immagine Docker utilizza Java e Maven, sia il Maven Surefire Plugin che il Maven FailedSafe Plugin. Se l'immagine Docker è implementata con altri linguaggi di programmazione o con altri corridori di test, controlla la documentazione relativa agli strumenti selezionati per sapere come generare i rapporti JUnit XML.
Talvolta, i test devono caricare i file nell’applicazione in fase di test. Per mantenere la flessibilità nella distribuzione del selenio rispetto ai test, non è possibile caricare direttamente una risorsa direttamente in selenio. Al contrario, il caricamento di un file passa attraverso alcuni passaggi intermedi:
UPLOAD_URL
. Il caricamento deve essere eseguito in una richiesta POST con un modulo multiparte. Il modulo multiparte deve avere un singolo campo di file. Equivale a curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
. Consulta la documentazione e le librerie del linguaggio di programmazione utilizzato nell’immagine Docker per sapere come eseguire tale richiesta HTTP.200 OK
di tipo text/plain
. Il contenuto della risposta è un handle di file opaco. Potete usare questa maniglia al posto del percorso di un file in un elemento <input>
per testare i caricamenti di file nell'applicazione.