Exécuter des tests dans votre pipeline

Un test, n'importe quel pipeline

gtr-cli, l'outil en ligne de commande, exécute un test exactement comme le bouton Exécuter le test : mêmes assertions, même rapport, même historique.Il ajoute ce dont un pipeline a besoin : un code de sortie, des fichiers de résultats que votre outil de CI comprend, et toutes les preuves d'un échec dans un seul dossier.

jobs:  gui-tests:    runs-on: [self-hosted, windows]    steps:      - run: gtr-cli run tests --format github --junit results.xml

Préparer la machine de build

Un test GUI se rejoue sur un écran réel, la machine qui l'exécute en a donc besoin d'un.

Créez la clé sur votre page de compte, sous Clés machine, puis lancez ceci une fois sur l'agent, avec le compte Windows que le pipeline utilise :

gtr-cli login --key GTS-XXXX-XXXX-XXXX-XXXX

gtr-cli whoami indique si l'agent est connecté et jusqu'à quand.Sans connexion, une exécution ne démarre pas : elle affiche une ligne commençant par COULD NOT RUN et se termine avec le code de sortie 3.

Agents de build : clés machine

Votre première commande

Dans un terminal sur la machine de build, exécutez tous les tests d'un dossier :

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

--countdown 0 démarre aussitôt (personne n'est devant l'écran), --junit écrit le fichier de résultats que lit votre outil de CI, et --artifacts rassemble les vidéos, les rapports et les images des échecs dans un seul dossier.

gtr-cli check tests

Ce que votre pipeline reçoit en retour

Les exécutions arrivent aussi dans le dossier de résultats de chaque test, l'historique de GUI Test Runner-Recorder montre donc les exécutions du pipeline à côté des vôtres.

Des exemples prêts à l'emploi

jobs:
  gui-tests:
    runs-on: [self-hosted, windows]
    steps:
      - uses: actions/checkout@v4
      - run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --summary results\summary.md --artifacts results\artifacts
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: gui-test-results
          path: results

Construire une commande sans la saisir

Dans l'une ou l'autre application, Ligne de commande & CI/CD (dans le menu Fichier de GUI Test Studio, dans le menu Test de GUI Test Runner-Recorder) construit la commande pour vous : cochez les options voulues, copiez le résultat, ou copiez l'extrait prêt à l'emploi pour votre outil de CI avec vos vrais chemins.Son onglet Documentation explique chaque option.

Agrandir

Les options que vous utiliserez

gtr-cli help

Signaler les échecs dans Jira

Un test échoué peut devenir de lui-même un ticket Jira : les étapes pour reproduire, les images attendue et obtenue avec ce qui a changé entouré, le rapport d'anomalie en PDF et les preuves.La même anomalie revue, sur un autre build, navigateur ou appareil, ajoute un commentaire à son ticket ouvert au lieu d'en créer un second.

gtr-cli run tests --countdown 0 --jira on-failure --jira-project SCRUM --jira-labels ui-regression

La connexion vient de l'environnement, le jeton n'apparaît donc jamais dans une ligne de commande ni dans un journal de build : JIRA_BASE_URL (votre site Jira), JIRA_USER_EMAIL et JIRA_API_TOKEN.Dans votre outil de CI, gardez le jeton comme secret ou comme paramètre de type mot de passe.Sur un ordinateur où GUI Test Runner-Recorder est connecté à Jira, c'est sa connexion mémorisée qui est utilisée à la place.

Tout le parcours, avec un vrai ticket et un vrai build : Connecter Jira au rapport de confiance.

Les applications web sur une machine de build

Un test enregistré sur une application web ouvre son navigateur de lui-même, en mode kiosque plein écran, et le ferme à la fin.Sur une machine de build, cela demande la taille d'écran et la mise à l'échelle de l'enregistrement, un bureau ouvert et déverrouillé, et une exécution qui se termine par sa propre limite de temps.Ouvrir une application web dit ce qui se passe sinon et que faire.

Les mêmes notes se trouvent dans l'outil lui-même :

gtr-cli help web-apps

Chaque navigateur et appareil, dans le pipeline

Un test web créé pour plusieurs navigateurs et appareils les exécute tous avec --branch all, chacun avec sa propre entrée dans le fichier JUnit et son propre historique.Les téléphones, les tablettes et les autres branches sans fenêtre s'exécutent côte à côte, ils n'ont donc pas besoin d'un écran à eux.gtr-cli info liste le nom de chacun, et gtr-cli generate crée ceux qui manquent encore.Voir Chaque navigateur et chaque appareil à partir d'un seul enregistrement.

gtr-cli generate tests --branch missing
gtr-cli run tests --branch all --countdown 0 --junit results\junit.xml

Partager des tests sans leur enregistrement

Un fichier de test contient son enregistrement, dont vous avez besoin pour le modifier mais pas pour l'exécuter.Fichier, Exporter en test allégé (.GTR) dans GUI Test Studio écrit le même test sans lui : un fichier bien plus petit pour une machine de build ou un collègue qui ne fait qu'exécuter des tests. gtr-cli et GUI Test Runner-Recorder exécutent les fichiers .GTR comme n'importe quel test.

Quand utiliser un test allégé

Utilisez-le partout où un test ne fait que s'exécuter : une machine de build, l'ordinateur d'un testeur, un ensemble de tests qui doit voyager ou être conservé avec votre code.L'exécution d'un test allégé donne le même résultat et le même rapport que son test.

Gardez le test lui-même

Un test allégé ne peut pas être modifié : GUI Test Studio ne l'ouvre pas.Gardez le .GTS comme original, modifiez-le là, et exportez à nouveau après un changement.GUI Test Runner-Recorder peut aussi en exporter un, depuis son menu Test ou le bouton d'exportation sur la page du test.

Un test web avec plusieurs navigateurs et appareils

L'exportation demande quoi inclure.Chaque navigateur et appareil met chaque branche générée dans un seul fichier, prêt pour --branch all.Seulement l'enregistrement, ou seulement la branche affichée, crée un test allégé de celle-ci uniquement.Un test allégé ne peut qu'être exécuté : les nouveaux navigateurs et appareils sont créés à partir du .GTS.

Garder les tests avec votre code

Les tests sont des fichiers ordinaires : gardez-les dans votre dépôt à côté du code qu'ils testent, et chaque branche porte les tests qui lui correspondent.