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 facilement être généré en utilisant 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 personnes qui n’ont pas l’habitude d’effectuer des tests.
Les tests de l’interface utilisateur sont exécutés dans le cadre d’un point de contrôle qualité spécifique pour chaque pipeline Cloud Manager avec une étape de Tests de l’interface utilisateur personnaliséedans les pipelines de production ou 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 avec des tests é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.
-
Définissez le langage de programmation que vous souhaitez utiliser.
-
Pour Cypress, utilisez l’exemple de code du Référentiel d’exemples de test AEM.
-
Pour JavaScript et WDIO, utilisez l’exemple de code généré automatiquement dans le dossier
ui.tests
de votre référentiel Cloud Manager.note note NOTE Si votre référentiel a été créé avant la création automatique des dossiers ui.tests
par Cloud Manager, vous pouvez également générer la dernière version en date à l’aide de l’archétype de projet AEM. -
Pour Java et WebDriver, utilisez l’exemple de code du Référentiel d’exemples de test AEM.
-
Pour les autres langages de programmation, reportez-vous à la section Création de tests d’interface utilisateur dans ce document pour configurer le projet test.
-
-
Assurez-vous que le test de l’interface utilisateur est activé conformément à la section Accord préalable client de ce document.
-
Développez vos cas de test et exécutez les tests localement.
-
Validez votre code dans le référentiel Cloud Manager et exécutez un pipeline 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 :
- Génère une archive contenant un
Dockerfile
et tout autre fichier nécessaire pour créer l’image Docker avec vos tests. - Balise l’archive avec le classificateur
ui-test-docker-context
.
La méthode la plus simple pour y parvenir 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
. En outre, il répertorie les fichiers qui doivent être inclus dans l’archive, parmi lesquels les éléments suivants.
- Un
Dockerfile
, obligatoire pour la création de l’image Docker - Le script
wait-for-grid.sh
dont les objectifs sont décrits ci-dessous - Des tests d’interface utilisateur, implémentés par un projet Node.js dans le dossier
test-module
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.
L’archive contenant le contexte de création Docker est automatiquement récupérée par Cloud Manager, qui crée l’image Docker contenant vos tests pendant ses 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.
- Le nom du fichier doit être
testing.properties
. - Le contenu du fichier doit être
ui-tests.version=1
. - Le fichier doit se trouver sous le sous-module Maven pour les tests de l’interface utilisateur, à côté du fichier
pom.xml
du sous-module de tests de l’interface utilisateur. - Le fichier doit se trouver à la racine du fichier
tar.gz
créé.
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 :
-
Pour le dossier
ui.tests
JavaScript généré à partir de l’archétype de projet AEM, vous pouvez exécuter la commande ci-dessous pour ajouter la configuration requise.code language-shell echo "ui-tests.version=1" > testing.properties if ! grep -q "testing.properties" "assembly-ui-test-docker-context.xml"; then awk -v line=' <include>testing.properties</include>' '/<include>wait-for-grid.sh<\/include>/ { printf "%s\n%s\n", $0, line; next }; 1' assembly-ui-test-docker-context.xml > assembly-ui-test-docker-context.xml.new && mv assembly-ui-test-docker-context.xml.new assembly-ui-test-docker-context.xml fi
-
L’indicateur d’accord préalable est déjà défini pour les exemples de test Cypress et Java Selenium fournis.
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.
SELENIUM_BASE_URL
http://my-ip:4444
SELENIUM_BROWSER
chrome
AEM_AUTHOR_URL
http://my-ip:4502/context-path
AEM_AUTHOR_USERNAME
admin
AEM_AUTHOR_PASSWORD
admin
AEM_PUBLISH_URL
http://my-ip:4503/context-path
AEM_PUBLISH_USERNAME
admin
AEM_PUBLISH_PASSWORD
admin
REPORTS_PATH
/usr/src/app/reports
UPLOAD_URL
http://upload-host:9090/upload
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')
- JavaScript : voir le module lib/config.js.
- Java : voir la classe Config.
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
- Les tests dans Cloud Manager sont exécutés par une personne administratrice technique.
- L’infrastructure en conteneur qui est prévue pour les tests fonctionnels est restreinte par les limites suivantes :
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.
- Lecture de l’URL du service Selenium à partir de la variable d’environnement
SELENIUM_BASE_URL
. - Sondage à intervalle régulier vers le point d’entrée de statut exposé par l’API Selenium.
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 Adobe s’en occupent avec le script wait-for-grid.sh
, qui est exécuté au démarrage de Docker et ne lance l’exécution réelle du test 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.
- JavaScript : commande takeScreenshot
- Java : commandes
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 à partir de Cloud Manager. Pour cela, cliquez sur le bouton Download Details
sous l’étape Tests de l’interface utilisateur personnalisée.
Charger des fichiers upload-files
Les tests doivent parfois charger des fichiers vers l’application en cours de test. Afin que le déploiement de Selenium puisse s’adapter à vos tests, il n’est pas possible de charger directement une ressource vers Selenium. Au lieu de cela, le chargement d’un fichier nécessite de suivre les étapes suivantes.
-
Chargez le fichier à l’URL spécifiée par la variable d’environnement
UPLOAD_URL
.-
Le chargement doit être effectué dans une requête POST avec un formulaire en plusieurs parties.
-
Le formulaire en plusieurs parties doit comporter un seul champ de fichier.
-
Celui-ci doit être équivalent à
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
. -
Consultez la documentation et les bibliothèques du langage de programmation utilisé dans l’image Docker pour savoir comment exécuter une telle requête HTTP.
-
Les exemples de test d’Adobe fournissent des fonctions d’assistance pour le téléchargement de fichiers :
- JavaScript : voir la commande getFileHandleForUpload.
- Java : voir la classe FileHandler.
-
-
Si le chargement aboutit, la requête renvoie une réponse
200 OK
de typetext/plain
.- Le contenu de la réponse est une gestion de fichier opaque.
- Vous pouvez utiliser cette gestion à la place d’un chemin de fichier dans un élément
<input>
pour tester les chargements de fichiers dans votre application.
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, il est recommandé d’exécuter localement les tests de l’interface utilisateur vers le SDK AEM as a Cloud Service ou dans une instance AEM as a Cloud Service réelle.
Exemple de test Cypress cypress-sample
-
Ouvrez une interface shell et accédez au dossier
ui.tests/test-module
dans votre référentiel -
Installez Cypress et autres prérequis
code language-shell npm install
-
Définissez des variables d’environnement requises pour l’exécution du test
code language-shell export AEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com export AEM_AUTHOR_USERNAME=<user> export AEM_AUTHOR_PASSWORD=<password> export AEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com export AEM_PUBLISH_USERNAME=<user> export AEM_PUBLISH_PASSWORD=<password> export REPORTS_PATH=target/
-
Exécutez des tests avec l’une des commandes suivantes :
code language-shell npm test # Using default Cypress browser npm run test-chrome # Using Google Chrome browser npm run test-firefox # Using Firefox browser
target/
de votre référentiel.Exemple de test JavaScript WebdriverIO javascript-sample
-
Ouvrez une interface shell et accédez au dossier
ui.tests
dans votre référentiel -
Exécutez la commande ci-dessous pour lancer les tests à l’aide de Maven.
code language-shell mvn verify -Pui-tests-local-execution \ -DAEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_AUTHOR_USERNAME=<user> \ -DAEM_AUTHOR_PASSWORD=<password> \ -DAEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \ -DAEM_PUBLISH_USERNAME=<user> \ -DAEM_PUBLISH_PASSWORD=<password>
- Vous lancez ainsi une instance autonome de Selenium et exécutez les tests sur cette instance.
- Les fichiers journaux sont stockés dans le dossier
target/reports
de votre référentiel - Votre machine doit utiliser la dernière version de Chrome, car le test télécharge automatiquement la dernière version de ChromeDriver à des fins de test.
Exemple de test Java Selenium WebDriver java-sample
-
Ouvrez une interface shell et accédez au dossier
ui.tests/test-module
dans votre référentiel -
Exécutez les commandes ci-dessous pour lancer les tests à l’aide de Maven
code language-shell # Start selenium docker image (for x64 CPUs) docker run --platform linux/amd64 -d -p 4444:4444 selenium/standalone-chrome-debug:latest # Start selenium docker image (for ARM CPUs) docker run -d -p 4444:4444 seleniarm/standalone-chromium # Run the tests using the previously started Selenium instance mvn verify -Pui-tests-local-execution -DSELENIUM_BASE_URL=http://<server>:4444
target/reports
de votre référentiel.