Tests de l’interface utilisateur ui-testing

Le test d’interface utilisateur personnalisé est une fonctionnalité facultative qui vous permet de créer et d’exécuter automatiquement des tests d’interface utilisateur pour vos applications.

Vue d’ensemble custom-ui-testing

AEM fournit une suite intégrée de points de contrôle de qualité Cloud Manager pour garantir la fluidité de la mise à jour des applications personnalisées. En particulier, les points de contrôle informatiques prennent déjà en charge la création et l’automatisation des tests personnalisés à l’aide des API d’AEM.

Les tests de l’interface utilisateur sont empaquetés dans une image Docker afin de permettre un large choix de langages et de structures (telles que Cypress, Selenium, Java et Maven, ou encore Javascript). En outre, un projet de tests d’interface utilisateur peut être facilement généré à l’aide de l’archétype de projet AEM.

Adobe encourage l’utilisation de Cypress, car il propose un rechargement en temps réel et une attente automatique, ce qui permet de gagner du temps et d’améliorer la productivité pendant les tests. Cypress fournit également une syntaxe simple et intuitive, ce qui facilite l’apprentissage et l’utilisation, même pour les utilisateurs et utilisatrices qui ne connaissent pas les tests.

Les tests de l’interface utilisateur s’exécutent en tant que point de contrôle qualité à l’étape Tests personnalisés de l’interface utilisateur, obligatoire dans les pipelines de production et facultatif dans les pipelines hors production. Tous les tests de l’interface utilisateur, y compris les régressions et les nouvelles fonctionnalités, permettent de détecter et de signaler des erreurs.

Contrairement aux tests fonctionnels personnalisés qui sont des tests HTTP écrits en Java, les tests de l’interface utilisateur peuvent être une image Docker. Les tests peuvent être écrits dans n’importe quelle langue, à condition qu’ils respectent les conventions définies dans la section ​ Création de tests d’interface utilisateur.

Prise en main des tests d’interface utilisateur get-started-ui-tests

Cette section décrit les étapes requises pour configurer des tests d’interface utilisateur pour une exécution dans Cloud Manager.

Création de tests de l’interface utilisateur building-ui-tests

Un projet Maven génère un contexte de build Docker. Ce contexte de build Docker décrit comment créer une image Docker contenant les tests de l’interface utilisateur que les utilisateurs et utilisatrices de Cloud Manager utilisent pour générer une image Docker contenant les tests de l’interface utilisateur réels.

Cette section décrit les étapes à suivre pour ajouter un projet de tests de l’interface utilisateur à votre référentiel.

Générer un contexte Docker Build generate-docker-build-context

Pour générer un contexte Docker Build, vous avez besoin d’un module Maven qui :

La méthode la plus simple consiste à configurer le plug-in Maven Assembly pour créer l’archive de contexte de création Docker et lui affecter le classificateur approprié.

Vous pouvez créer des tests de l’interface utilisateur avec différentes technologies et structures, mais cette section suppose que votre projet est présenté de la même manière que le suivant.

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

Le fichier pom.xml prend en charge la création Maven. Ajoutez une exécution au module d’extension Maven Assembly semblable à celle qui suit.

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

Cette exécution indique au module d’extension Maven Assembly de créer une archive basée sur les instructions contenues dans assembly-ui-test-docker-context.xml, nommée descripteur d’assemblage dans le jargon du plug-in. Le descripteur d’assemblage répertorie tous les fichiers qui doivent faire partie de l’archive.

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

Le descripteur d’assemblage demande au module d’extension de créer une archive de type .tar.gz et lui affecte le classificateur ui-test-docker-context. De plus, il répertorie les fichiers qui doivent être inclus dans l’archive, notamment les éléments suivants :

Le descripteur d’assemblage exclut également certains fichiers qui pourraient être générés lors de l’exécution locale des tests de l’interface utilisateur. Cela garantit une archive plus petite et accélère la création.

Cloud Manager récupère automatiquement l’archive de contexte de création Docker et crée l’image de test pendant les pipelines de déploiement. Cloud Manager exécute ensuite l’image Docker pour réaliser les tests de l’interface utilisateur sur votre application.

Le build doit produire zéro ou une archive. S’il ne produit aucune archive, l’étape de test est effectuée par défaut. Si le build produit plusieurs archives, celle qui est sélectionnée est non déterministe.

Accord préalable client customer-opt-in

Pour que Cloud Manager puisse créer et exécuter vos tests d’interface utilisateur, vous devez souscrire à cette fonctionnalité en ajoutant un fichier à votre référentiel.

La génération et l’exécution des tests de l’interface utilisateur seront ignorées si ce fichier n’est pas présent.

Pour inclure un fichier testing.properties dans l’artefact de build, ajoutez une instruction include dans le fichier 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>
[...]

Si vous utilisez les exemples fournis par Adobe :

Rédiger des tests de l’interface utilisateur writing-ui-tests

Cette section décrit les conventions que l’image Docker contenant vos tests de l’interface utilisateur doit respecter. L’image Docker est créée à partir du contexte de création Docker décrit dans la section précédente.

Variables d’environnement environment-variables

Les variables d’environnement suivantes seront transmises à votre image Docker au moment de l’exécution, en fonction de votre framework.

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

Les exemples de test d’Adobe fournissent des fonctions d’assistance pour accéder aux paramètres de configuration :

Cypress : utiliser la fonction standard Cypress.env('VARIABLE_NAME')

Générer des rapports de test generate-test-reports

L’image Docker doit générer des rapports de test au format XML JUnit et les enregistrer dans le chemin spécifié par la variable d’environnement REPORTS_PATH. Le format XML JUnit est un format très répandu pour les rapports de résultats de tests. Si l’image Docker utilise Java et Maven, les modules de test standard tels que le plug-in Maven Surefire et le plug-in Maven Failsafe peuvent générer ces rapports prêts à l’emploi.

Si l’image Docker est implémentée avec d’autres langages de programmation ou des exécuteurs de tests, consultez la documentation des outils choisis pour savoir comment générer des rapports XML JUnit.

Prérequis prerequisites

Détails spécifiques à Selenium

Attendre la préparation de Selenium waiting-for-selenium

Avant le début des tests, l’image Docker doit garantir que le serveur Selenium est opérationnel. L’attente du service de Selenium est un processus en deux étapes.

Une fois que le point d’entrée du statut de Selenium donne une réponse positive, les tests peuvent débuter.

Les exemples de test de l’interface utilisateur d’Adobe utilisent wait-for-grid.sh. Il s’exécute au démarrage de Docker et ne lance les tests qu’une fois la grille prête.

Captures d’écran et vidéos capture-screenshots

L’image Docker peut générer une sortie de test supplémentaire (par exemple, des captures d’écran ou des vidéos) et les enregistrer dans le chemin spécifié par la variable d’environnement REPORTS_PATH. Tout fichier situé sous la variable d’environnement REPORTS_PATH est inclus dans l’archive des résultats du test.

Les exemples de test fournis par Adobe créent par défaut des captures d’écran pour tout test ayant échoué.

Vous pouvez utiliser les fonctions d’assistance pour créer des captures d’écran durant vos tests.

Si une archive de résultats de test est créée lors de l’exécution d’un test de l’interface utilisateur, vous pouvez la télécharger depuis Cloud Manager en cliquant sur le bouton Download Details sous l’étape Test personnalisé de l’interface utilisateur ​.

Charger des fichiers upload-files

Les tests doivent parfois charger des fichiers vers l’application en cours de test. Pour que le déploiement de Selenium puisse s’adapter à vos tests, il n’est pas possible de charger une ressource directement dans Selenium. Au lieu de cela, le chargement d’un fichier nécessite de suivre les étapes suivantes.

Détails spécifiques à Cypress

Configurer le proxy HTTP

Le point d’entrée du conteneur Docker doit vérifier la valeur de la variable d’environnement PROXY_HOST.

Si cette valeur est vide, aucune étape supplémentaire n’est nécessaire et les tests doivent être exécutés sans utiliser de proxy HTTP.

S’il n’est pas vide, le script de point d’entrée doit :

Vous trouverez un exemple d’implémentation dans le point d’entrée du module de test d’exemple Cypress sur GitHub.

Détails spécifiques au dramaturge

Configurer le proxy HTTP

Tout comme Cypress, les tests doivent utiliser le proxy HTTP si une variable d’environnement PROXY_HOST non vide est fournie.

Dans ce cas, les modifications suivantes doivent être apportées.

Dockerfile

Installer cURL et libnss3-tools, qui fournit des certutil.

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

Script du point d’entrée

Incluez un script Bash qui, si PROXY_HOST variable d’environnement est fournie, effectue les opérations suivantes :

Exemple d’implémentation :

# 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

Configuration de Playwright

Modifiez la configuration du auteur de lecture (par exemple dans playwright.config.js) pour utiliser un proxy au cas où la variable d’environnement HTTP_PROXY serait définie.

Exemple d’implémentation :

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

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

Exécuter les tests de l’interface utilisateur localement run-ui-tests-locally

Avant d’activer les tests de l’interface utilisateur dans un pipeline Cloud Manager, Adobe vous recommande d’exécuter localement les tests de l’interface utilisateur sur le SDK AEM as a Cloud Service. Vous pouvez également l’exécuter sur une instance AEM as a Cloud Service réelle.

Exemple de test Cypress cypress-sample

Exemple de test JavaScript WebdriverIO javascript-sample

Exemple de test Playwright playwright-sample

Exemple de test Java Selenium WebDriver java-sample