Tester le mode sombre, d'autres langues, d'autres écrans : un seul test pour toutes les variantes

Pour tester le mode sombre, d'autres langues et d'autres écrans sans copier le test, gardez un seul test dont les assertions ont une version par variante.Une exécution choisit la variante, et les étapes restent les mêmes.

C'est l'un des problèmes les plus courants de l'automatisation des tests.Un test réussit en mode clair sur votre poste, puis échoue en mode sombre, en français ou sur l'ordinateur portable d'un collègue, alors que rien n'est cassé.

Pourquoi un test échoue-t-il en mode sombre alors que rien n'est cassé ?

Dans GUI Test Studio, ce qu'une assertion attend est la cible visuelle d'une assertion visuelle, le texte attendu d'une assertion de texte, le format d'une assertion de texte dynamique ou l'agencement d'une assertion de disposition.L'enregistrement donne à chaque assertion sa première apparence attendue, appelée la version par défaut.

Mode sombre, autre langue, autre écran : ce qui change sur un écran correct

Un même écran peut à juste titre avoir une autre apparence.L'application n'est pas cassée, elle est affichée dans une autre variante, et une assertion qui n'a qu'une version ne peut pas faire la différence.

Pourquoi copier le test pour chaque variante ne tient pas

Quand un écran correct échoue sans cesse dans une variante, les équipes ont en général recours à l'un de trois raccourcis.

Pourquoi un test qui réussit peut quand même manquer ce que voient les utilisateurs, c'est le sujet de l'article Les bugs visuels que vos tests automatisés manquent.Pourquoi une assertion qui échoue sans raison est pire que pas d'assertion du tout, c'est expliqué dans Tests instables et faux positifs.

Ce qu'il faut dans un framework de test codé

Dans un framework codé comme Playwright, Selenium ou Cypress, c'est à vous de construire et d'entretenir les variantes dans le code.

L'idée est la même : une variante, un ensemble d'attentes.Ce qui diffère, c'est ce que vous devez écrire et entretenir pour y arriver.

Un seul test pour toutes les variantes : les profils de référence

GUI Test Studio, qui automatise les tests de bout en bout sous Windows sans code, garde chaque version dans le test.Vous nommez vos variantes comme des profils de référence, par exemple Mode sombre, Français, Écran 4K ou Windows 10.Chaque assertion peut alors garder une version de ce qu'elle attend par profil, à côté de sa version par défaut.

Chaque type d'assertion peut contenir des versions : assertions visuelles, assertions de texte, assertions de texte dynamique et assertions de disposition.Dans une assertion de groupe, chaque membre contient les siennes.Voir le guide des références pour chaque fenêtre concernée.

Ce qui change d'une variante à l'autre, et ce qui ne change jamais

Un profil change ce qu'une assertion attend.Il ne change jamais la façon dont l'assertion le cherche.

Tester une application en plusieurs langues : les étapes changent aussi

Un test dans une autre langue a souvent besoin de plus que d'autres images.Il saisit d'autres mots, ouvre une autre adresse ou téléverse un autre fichier.Ainsi, chaque étape du test peut contenir la version d'un profil pour ce qu'elle fait, tandis que son emplacement à l'écran et son moment restent partagés.

Un raccourci peut aussi différer : dans Microsoft Word en français, le gras est Ctrl+G et non Ctrl+B, donc l'étape Appui de touche contient une version Français.

La façon dont une assertion de texte lit et compare un texte est expliquée dans Assertions de texte.

Comment ajouter le mode sombre à un test existant, étape par étape

Le moyen le plus rapide de remplir un profil est une exécution sous ce profil.Les assertions dont l'apparence diffère échouent, vous les examinez, et vous gardez celles qui sont justes.

1. 1

   Nommer le profil

   Dans Paramètres, Paramètres du projet, ajoutez un profil de référence nommé Mode sombre dans la carte Profils de référence.Un profil n'est qu'un nom tant que ses assertions n'ont pas reçu leurs versions.

2. 2

   Exécuter le test sous le profil

   Passez votre application en mode sombre.Sur la page du test dans GUI Test Runner-Recorder, choisissez Mode sombre dans la ligne Référence, puis cliquez sur Exécuter le test.

   

   Agrandir

3. 3

   Examiner chaque assertion échouée

   Les assertions se comparent encore à l'apparence claire, donc celles dont l'apparence diffère échouent.Ouvrez chacune d'elles dans le rapport de confiance et décidez si l'apparence sombre est juste.

4. 4

   Accepter les apparences sombres qui sont justes

   Cliquez sur Accepter le résultat obtenu comme référence pour « Mode sombre » sur chaque assertion que vous avez examinée.L'apparence claire par défaut reste telle qu'elle était.

   

   Agrandir

5. 5

   Sauvegarder, puis exécuter à nouveau

   Sauvegardez les modifications du rapport dans le test, et exécutez-le encore une fois sous Mode sombre.Chaque assertion se compare maintenant à sa propre version sombre.

Ou capturer la version dans GUI Test Studio

Sélectionnez une assertion, ouvrez son onglet Références et sélectionnez le profil.Chaque champ du panneau Propriétés montre maintenant la version de ce profil, et une modification de ce que l'assertion attend va dans cette version.Capturer... lance une capture d'écran avec la zone de l'assertion tracée là où elle se trouvait, et Capturer la même zone prend l'image du profil à cet endroit même.

Vous pouvez aussi demander à votre assistant IA d'ajouter un profil ou de capturer une version, avec Créer un test depuis une consigne.

Quand l'application change volontairement : accepter la nouvelle apparence en un clic

Une nouvelle apparence s'accepte quand l'application change volontairement.N'acceptez que ce que vous avez examiné, et gardez un moyen de revenir en arrière.

Mettre à jour un test après un changement détaille l'acceptation dans le rapport, et le rapport de confiance explique tout ce qu'il affiche.

Exécuter chaque variante en CI/CD

Une exécution utilise un profil.Dans GUI Test Runner-Recorder, c'est la ligne Référence de la page du test.Sur un agent de build, gtr-cli prend --baseline-profile suivi du nom du profil.

gtr-cli run tests\Checkout.GTS --junit results\default.xml
gtr-cli run tests\Checkout.GTS --baseline-profile "Dark mode" --junit results\dark.xml
gtr-cli run tests\Checkout.GTS --baseline-profile "French" --junit results\french.xml

Exécuter des tests dans votre pipeline liste toutes les options de gtr-cli.

Les navigateurs et les appareils se gèrent autrement

Un test web n'a pas besoin d'un profil par navigateur ou appareil : GUI Test Runner-Recorder génère une version du test enregistré pour Chrome, Edge, Firefox et des téléphones et tablettes émulés, avec des images relevées sur chacun.Voir Des tests multi-navigateurs à partir d'un seul enregistrement.

Les profils de référence servent à ce qui change l'apparence de la même application sur le même type d'écran : un thème, une langue, une mise à l'échelle, une version de Windows ou une édition de votre application.Cela fonctionne aussi bien pour les applications de bureau que pour les applications web, les jeux et les téléphones.

Ce qu'il faut savoir avant de commencer

Points clés

• 1Un test qui attend une seule apparence fait échouer un écran correct en mode sombre, dans une autre langue, avec une autre mise à l'échelle ou sur une autre version de Windows.
• 2Les copies et les assertions assouplies ne tiennent pas : les copies divergent, et une assertion assouplie cache de vrais bugs.
• 3GUI Test Studio garde chaque variante dans un seul test, une version par profil de référence, pour chaque assertion et chaque étape.
• 4Où regarder, combien de temps attendre et avec quelle rigueur restent partagés, donc aucune variante ne rend le test plus indulgent.
• 5Une exécution choisit une variante, et une nouvelle apparence vient de l'acceptation d'un résultat examiné dans le rapport de confiance.

Questions

Playwright, Selenium, Cypress, Microsoft Word et Windows sont des marques de leurs propriétaires respectifs.