Test dell'interfaccia utente

I test dell’interfaccia utente sono test basati su Selenium inseriti 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 l’esecuzione. Quando si esegue l'immagine Docker, viene eseguito automaticamente il provisioning di un server Selenium. Le convenzioni di runtime descritte di seguito consentono al codice di test di accedere sia al server Selenium che alle istanze AEM in fase di test.

Creazione di test dell’interfaccia utente

I test dell’interfaccia utente si basano su un contesto di build 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, la Archetipo di progetto AEM può generare un progetto di test dell’interfaccia utente .

Generare un contesto di creazione Docker

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

• Produce un archivio contenente un Dockerfile e tutti gli altri file necessari per creare l'immagine Docker con i test.
• Assegna tag all’archivio con la ui-test-docker-context classificatore.

Il modo più semplice per ottenere questo risultato è quello di configurare il Plug-in assembly Maven per creare l'archivio contestuale della build Docker e assegnargli il classificatore corretto.

Puoi creare test dell’interfaccia utente con diverse tecnologie e framework, ma questa sezione presuppone che il progetto sia disposto in modo simile al seguente.

├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│   ├── package.json
│   ├── index.js
│   └── wdio.conf.js
└── wait-for-grid.sh

La pom.xml il file si occupa della build Maven. Aggiungi un’esecuzione al plugin Maven Assembly in modo simile al seguente.

<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 plugin Maven Assembly di creare un archivio in base alle istruzioni contenute in assembly-ui-test-docker-context.xml, chiamato un "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'assieme indica al plug-in di creare un archivio di tipo .tar.gz e assegna le ui-test-docker-context classificatore. Inoltre, elenca i file che devono essere inclusi nell'archivio:

• A Dockerfile, obbligatorio per la creazione dell’immagine Docker.
• La wait-for-grid.sh script, le cui finalità sono descritte di seguito.
• I test effettivi dell’interfaccia utente, implementati da un progetto Node.js in test-module cartella.

Il descrittore di 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 della build Docker viene automaticamente raccolto 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 rispetto all’applicazione.

La build deve produrre zero o un archivio. Se genera un archivio a zero, il passaggio di test viene superato per impostazione predefinita. Se la build produce più di un archivio, l'archivio selezionato non è deterministico.

Creazione di test dell’interfaccia utente

Questa sezione descrive le convenzioni che l’immagine Docker contenente i test dell’interfaccia utente deve seguire. L’immagine Docker è creata in base al contesto della build Docker descritto nella sezione precedente.

Variabili di ambiente

Le seguenti variabili di ambiente verranno passate all’immagine Docker in fase di esecuzione.

In attesa che il selenio sia pronto

Prima dell'avvio dei test, è responsabilità dell'immagine Docker assicurarsi che il server Selenium sia in esecuzione. L'attesa del servizio Selenium è un processo in due fasi:

1. Leggi l’URL del servizio Selenium dal SELENIUM_BASE_URL variabile di ambiente.
2. Sondaggio a intervalli regolari endpoint di stato esposti dall’API Selenium.

Una volta che l'endpoint di stato di Selenium risponde con una risposta positiva, i test possono finalmente iniziare.

Generare i report di test

L’immagine Docker deve generare rapporti di test 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, entrambe le Plug-in del surefire Maven e Plug-in Maven FailureSafe. Se l'immagine Docker è implementata con altri linguaggi di programmazione o runners di test, controlla la documentazione relativa agli strumenti selezionati per sapere come generare report JUnit XML.

Caricare file (#upload-files)

A volte i test devono caricare i file nell'applicazione sotto test. Al fine di mantenere flessibile la distribuzione di Selenium rispetto ai test, non è possibile caricare direttamente una risorsa direttamente in Selenium. Il caricamento di un file passa attraverso alcuni passaggi intermedi:

1. Carica il file all’URL specificato dal UPLOAD_URL variabile di ambiente. 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". Per informazioni su come eseguire una richiesta HTTP, consulta la documentazione e le librerie del linguaggio di programmazione utilizzato nell’immagine Docker .
2. Se il caricamento ha esito positivo, la richiesta restituisce un 200 OK risposta del tipo text/plain. Il contenuto della risposta è un handle di file opaco. Puoi utilizzare questo handle al posto del percorso di un file in un <input> per testare il caricamento di file nell'applicazione.