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

NOTA

Per utilizzare i test dell’interfaccia utente descritti in questa pagina, è necessario aggiornare le pipeline di stage e produzione create prima del 10 febbraio 2021.
Per informazioni sulla configurazione della pipeline, consulta Configurazione della pipeline CI-CD .

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, il AEM Project Archetype 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 il classificatore ui-test-docker-context .

Il modo più semplice per ottenere questo risultato è configurare il plugin di assemblaggio Maven per creare l'archivio di contesto della build Docker e assegnargli il classificatore giusto.

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

Il file pom.xml 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 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 classificatore ui-test-docker-context. Inoltre, elenca i file che devono essere inclusi nell'archivio:

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

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.

Test di scrittura 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.

Variabile Esempi Descrizione
SELENIUM_BASE_URL http://my-ip:4444 URL del server Selenium
SELENIUM_BROWSER chrome, firefox Implementazione del browser utilizzata dal server Selenium
AEM_AUTHOR_URL http://my-ip:4502/context-path URL dell’istanza di authoring AEM
AEM_AUTHOR_USERNAME admin Nome utente per accedere all’istanza di authoring AEM
AEM_AUTHOR_PASSWORD admin Password per accedere all'istanza di authoring AEM
AEM_PUBLISH_URL http://my-ip:4503/context-path URL dell’istanza di pubblicazione AEM
AEM_PUBLISH_USERNAME admin Nome utente per accedere all'istanza di pubblicazione AEM
AEM_PUBLISH_PASSWORD admin Password per accedere all'istanza di pubblicazione AEM
REPORTS_PATH /usr/src/app/reports Percorso in cui salvare il report XML dei risultati del test
UPLOAD_URL http://upload-host:9090/upload URL a cui deve essere caricato il file per renderlo accessibile a Selenium

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 dalla variabile di ambiente SELENIUM_BASE_URL .
  2. Effettua un polling a intervalli regolari all' endpoint di stato esposto 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, sia il plug-in Maven Surefire che il 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 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". 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 una risposta 200 OK di tipo text/plain. Il contenuto della risposta è un handle di file opaco. Puoi utilizzare questo handle al posto di un percorso di file in un elemento <input> per testare il caricamento di file nell'applicazione.

In questa pagina