Test interfaccia utente

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.

Creazione di test dell'interfaccia utente

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.

Generare un contesto di build Docker

Per generare un contesto di creazione Docker, è necessario un modulo Maven che:

• Genera un archivio contenente un Dockerfile e tutti gli altri file necessari per creare l'immagine Docker con i test.
• Assegna tag all'archivio con il classificatore 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:

• A Dockerfile, obbligatorio per la creazione dell'immagine Docker.
• Lo script wait-for-grid.sh, le cui finalità sono descritte di seguito.
• I test dell'interfaccia utente effettivi, implementati da un progetto Node.js nella cartella 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.

Test dell'interfaccia utente di scrittura

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.

Variabili di ambiente

Le seguenti variabili di ambiente verranno trasmesse all'immagine Docker in fase di esecuzione.

In attesa che il selenio sia pronto

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:

1. Leggere l'URL del servizio Selenium dalla variabile di ambiente SELENIUM_BASE_URL.
2. Sondaggio a intervalli regolari sull'endpoint stato esposto dall'API Selenium.

Una volta che l'endpoint di stato del selenio risponde con una risposta positiva, i test possono finalmente avviarsi.

Generare i report di test

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.

Caricare i file (#upload-files)

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:

1. Caricate il file nell’URL specificato dalla variabile di ambiente 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.
2. Se il caricamento ha esito positivo, la richiesta restituisce una risposta 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.