Test dell’interfaccia utente ui-testing

I test dell’interfaccia utente personalizzati sono una funzione facoltativa che consente di creare ed eseguire automaticamente i test dell’interfaccia utente per le applicazioni.

Panoramica custom-ui-testing

AEM fornisce una suite integrata di gate di qualità di Cloud Manager per garantire una fluida esperienza di aggiornamento delle applicazioni personalizzate. In particolare, i gate di test IT supportano già la creazione e automazione dei test personalizzati utilizzando le API di AEM.

I test dell’interfaccia utente sono inclusi in un’immagine Docker per consentire un’ampia scelta in termini di linguaggio e framework (come Cypress, Selenium, Java e Maven e JavaScript). Inoltre, un progetto di test dell'interfaccia utente può essere facilmente generato utilizzando Archetipo progetto AEM.

Adobe incoraggia l’utilizzo di Cypress, in quanto offre il ricaricamento in tempo reale e l’attesa automatica, che consente di risparmiare tempo e migliora la produttività durante il test. Cypress fornisce anche una sintassi semplice e intuitiva, che lo rende facile da imparare e utilizzare, anche per gli utenti che non conoscono ancora i test.

I test dell'interfaccia utente vengono eseguiti come gate di qualità nel passaggio Test dell'interfaccia utente personalizzati, obbligatorio nelle pipeline di produzione e facoltativo nelle pipeline non di produzione. Tutti i test dell’interfaccia utente, compresi la regressione e le nuove funzionalità, consentono di rilevare e segnalare gli errori.

A differenza dei test funzionali personalizzati, che sono test HTTP scritti in Java, i test dell’interfaccia utente possono essere un’immagine Docker. I test possono essere scritti in qualsiasi lingua, purché rispettino le convenzioni definite nella sezione Generazione dei test dell'interfaccia utente.

Introduzione ai test dell’interfaccia utente get-started-ui-tests

In questa sezione vengono descritti i passaggi necessari per configurare i test dell’interfaccia utente per l’esecuzione in Cloud Manager.

Creazione dei test dell’interfaccia utente building-ui-tests

Un progetto Maven genera un contesto di build Docker. Questo contesto build di Docker descrive come creare un’immagine Docker contenente i test dell’interfaccia utente che Cloud Manager utilizza per generare un’immagine Docker contenente i test effettivi dell’interfaccia utente.

In questa sezione vengono descritti i passaggi necessari per aggiungere un progetto di test dell’interfaccia utente all’archivio.

Generare un contesto build di Docker generate-docker-build-context

Per generare un contesto build Docker è necessario un modulo Maven che:

Il modo più semplice consiste nel configurare il plug-in Maven Assembly per creare l'archivio di contesto di build Docker e assegnare a questo il classificatore corretto.

Puoi creare i test dell’interfaccia utente con diverse tecnologie e framework, ma questa sezione presuppone che il progetto sia 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 simile alla seguente al plug-in Maven Assembly.

<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 Maven Assembly di creare un archivio in base alle istruzioni contenute in assembly-ui-test-docker-context.xml, che prende il nome di descrittore assembly nel gergo del plug-in. Il descrittore 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 assembly fornisce al plug-in istruzioni per creare un archivio di tipo .tar.gz e assegna a questo il classificatore ui-test-docker-context. Inoltre, elenca i file che devono essere inclusi nell’archivio, inclusi i seguenti:

Il descrittore assembly esclude inoltre alcuni file che potrebbero essere generati durante l’esecuzione locale dei test dell’interfaccia utente. Questo garantisce un archivio di dimensioni minori e generazioni più veloci.

Cloud Manager raccoglie automaticamente l’archivio del contesto di build Docker e crea l’immagine di test durante le pipeline di distribuzione. Alla fine, Cloud Manager esegue l’immagine Docker per eseguire i test dell’interfaccia utente per l’applicazione.

La generazione deve produrre zero archivi o un unico archivio. Se non produce archivi, il passaggio di test viene superato per impostazione predefinita. Se la generazione produce più di un archivio, l’archivio selezionato non è deterministico.

Consenso del cliente customer-opt-in

Affinché a Cloud Manager possa generare ed eseguire i test dell’interfaccia utente, devi fornire il consenso esplicito alla funzione aggiungendo un file all’archivio.

Se il file non è presente, la build e le esecuzioni dei test dell’interfaccia utente vengono ignorate.

Per includere un file testing.properties nell’artefatto della build, aggiungi un’istruzione include nel file assembly-ui-test-docker-context.xml.

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]

Se utilizzi gli esempi forniti da Adobe:

Scrittura dei test dell’interfaccia utente writing-ui-tests

Questa sezione descrive le convenzioni da seguire per l’immagine Docker contenente i test dell’interfaccia utente. L’immagine Docker viene generata in base al contesto di build Docker descritto nella sezione precedente.

Variabili di ambiente environment-variables

In fase di esecuzione, all’immagine Docker vengono passate le seguenti variabili di ambiente a seconda del framework.

* these values will be empty if there is no publish instance

Gli esempi di test di Adobe forniscono funzioni di supporto per accedere ai parametri di configurazione:

Cypress: utilizza la funzione standard Cypress.env('VARIABLE_NAME')

Generazione dei rapporti sui test generate-test-reports

L’immagine Docker deve generare rapporti sui test in formato JUnit XML e salvarli nel percorso specificato dalla variabile di ambiente REPORTS_PATH. Il formato JUnit XML è ampiamente utilizzato per la generazione di rapporti sui risultati dei test. Se l’immagine Docker utilizza Java e Maven, i moduli di test standard come Maven Surefire Plug-in e Maven Failsafe Plug-in possono generare tali rapporti in modo preconfigurato.

Se implementi l’immagine Docker con altri linguaggi di programmazione o esecuzione di test, consulta la documentazione relativa agli strumenti scelti per sapere come generare rapporti JUnit XML.

Prerequisiti prerequisites

Dettagli specifici per Selenium

Attesa del servizio Selenium waiting-for-selenium

Prima dell’avvio dei test, l’immagine Docker verifica che il server Selenium sia in esecuzione. L’attesa del servizio Selenium è un processo a due fasi.

Dopo aver ricevuto una risposta positiva dall’endpoint di stato di Selenium è possibile avviare i test.

Gli esempi di test dell'interfaccia utente di Adobe utilizzano wait-for-grid.sh. Viene eseguito all’avvio del Docker e avvia i test solo dopo che la griglia è pronta.

Acquisire schermate e video capture-screenshots

L’immagine Docker può generare un output di test aggiuntivo (ad esempio schermate o video) e salvarlo nel percorso specificato dalla variabile di ambiente REPORTS_PATH. Qualsiasi file trovato sotto REPORTS_PATH è incluso nell’archivio dei risultati del test.

Gli esempi di test forniti da Adobe per impostazione predefinita creano screenshot per tutti i test non riusciti.

Puoi utilizzare le funzioni di assistenza per creare screenshot tramite i test.

Se durante l'esecuzione di un test dell'interfaccia utente viene creato un archivio dei risultati del test, è possibile scaricarlo da Cloud Manager facendo clic sul pulsante Download Details nel passaggio Test dell'interfaccia utente personalizzati.

Caricamento dei file upload-files

I test a volte richiedono il caricamento di file nell’applicazione sottoposta a test. Per mantenere flessibile la distribuzione di Selenium rispetto ai test, non è possibile caricare una risorsa direttamente in Selenium. Per caricare un file è necessario seguire la procedura riportata di seguito.

Dettagli specifici di Cypress

Configurare il proxy HTTP

Il punto di ingresso del contenitore Docker deve verificare il valore della variabile di ambiente PROXY_HOST.

Se questo valore è vuoto, non sono necessari passaggi aggiuntivi e i test devono essere eseguiti senza utilizzare un proxy HTTP.

Se non è vuoto, lo script entrypoint deve:

Un esempio di implementazione è disponibile nel punto di ingresso del modulo di test Cypress Sample su GitHub.

Dettagli specifici del playwright

Configurare il proxy HTTP

Analogamente a Cypress, i test devono utilizzare il proxy HTTP se viene fornita una variabile di ambiente PROXY_HOST non vuota.

In tal caso, è necessario apportare le seguenti modifiche.

Dockerfile

Installa cURL e libnss3-tools, che fornisce certutil.

RUN apt -y update \
    && apt -y --no-install-recommends install curl libnss3-tools \
    && rm -rf /var/lib/apt/lists/*

Script Entrypoint

Includere uno script di base che, nel caso in cui venga fornita la variabile di ambiente PROXY_HOST, esegua le operazioni seguenti:

Esempio di implementazione:

# setup proxy environment variables and CA certificate
if [ -n "${PROXY_HOST:-}" ]; then
  if [ -n "${PROXY_HTTPS_PORT:-}" ]; then
    export HTTP_PROXY="https://${PROXY_HOST}:${PROXY_HTTPS_PORT}"
  elif [ -n "${PROXY_HTTP_PORT:-}" ]; then
    export HTTP_PROXY="http://${PROXY_HOST}:${PROXY_HTTP_PORT}"
  fi
  if [ -n "${PROXY_CA_PATH:-}" ]; then
    echo "installing certificate"
    mkdir -p $HOME/.pki/nssdb
    certutil -d sql:$HOME/.pki/nssdb -A -t "CT,c,c" -n "EaaS Client Proxy Root" -i $PROXY_CA_PATH
    export NODE_EXTRA_CA_CERTS=${PROXY_CA_PATH}
  fi
  if [ -n "${PROXY_OBSERVABILITY_PORT:-}" ] && [ -n "${HTTP_PROXY:-}" ]; then
    echo "waiting for proxy"
    curl --silent  --retry ${PROXY_RETRY_ATTEMPTS:-3} --retry-connrefused --retry-delay ${PROXY_RETRY_DELAY:-10} \
      --proxy ${HTTP_PROXY} --proxy-cacert ${PROXY_CA_PATH:-""} \
      ${PROXY_HOST}:${PROXY_OBSERVABILITY_PORT}
    if [ $? -ne 0 ]; then
      echo "proxy is not ready"
      exit 1
    fi
  fi
fi

Configurazione playwright

Modificare la configurazione del playwright (ad esempio in playwright.config.js) per utilizzare un proxy nel caso in cui sia impostata la variabile di ambiente HTTP_PROXY.

Esempio di implementazione:

const proxyServer = process.env.HTTP_PROXY || ''

// enable proxy if set
if (proxyServer !== '') {
 cfg.use.proxy = {
  server: proxyServer,
 }
}

Esecuzione locale dei test dell’interfaccia utente run-ui-tests-locally

Prima di attivare i test dell'interfaccia utente in una pipeline di Cloud Manager, Adobe consiglia di eseguire i test dell'interfaccia utente in locale con AEM as a Cloud Service SDK. In alternativa, esegui su un’istanza AEM as a Cloud Service effettiva.

Esempio di prova Cypress cypress-sample

Esempio di test WebdriverIO JavaScript javascript-sample

Esempio di prova di Playwright playwright-sample

Esempio di test Java Selenium WebDriver java-sample