Automatisation des tests WPF et tests d'interface WinForms sans code (et sans arbre d'accessibilité)
L'automatisation des tests WPF et les tests d'interface WinForms sans code : ce que votre application expose à un outil de test, ce qu'elle cache, et comment enregistrer, vérifier et exécuter un test à chaque build.
10 min de lecturePar Ait Nohaila, Chargée de développement commercial
La réponse courte
Pour automatiser les tests d'interface d'une application WPF, enregistrez un parcours une fois dans GUI Test Studio : chaque clic, chaque touche et chaque assertion deviennent un test qui trouve chaque contrôle par les informations d'accessibilité de l'application, ou à vue quand elle ne dit rien.
Ce guide s'adresse à un ingénieur QA ou à un développeur qui a une application WPF ou Windows Forms (WinForms) à tester.Il montre ce qu'une telle application dit à un outil de test et ce qu'elle cache, enregistre un test étape par étape, choisit les assertions qui survivent à une refonte, exécute le test à chaque build, et dit quand une bibliothèque orientée code reste le meilleur choix.
Ce qu'une application WPF ou WinForms expose à un outil de test, et ce qu'elle cache
WPF et WinForms décrivent tous deux leurs contrôles standard à Windows par UI Automation : un type, un nom, une place à l'écran et, quand le développeur en a défini un, un AutomationId.Un lecteur d'écran utilise cette description, comme tout outil de test qui trouve les contrôles par des localisateurs.La même application contient aussi des contrôles qui ne disent rien du tout.
| Type de contrôle | Ce que voit UI Automation | Comment un test le trouve |
|---|---|---|
| Un contrôle WPF standard avec un AutomationId : Button, TextBox, ListView, DataGrid | Son type, son nom, sa place, et l'identifiant que le développeur lui a donné | Par ce que dit l'application, immédiatement |
| Un contrôle WinForms standard : Button, TextBox, DataGridView | Son type, son texte et le Name du contrôle comme identifiant, quand il a été défini | Par ce que dit l'application |
| Une application WinForms dont les contrôles ont gardé leurs noms par défaut | Des types et des textes, avec des identifiants comme button1 qui ne veulent pas dire grand-chose | Par le texte et la place du contrôle, et à vue |
| Un contrôle que l'application dessine elle-même : un graphique, une jauge, un ruban, un canevas | Un seul rectangle, sauf si ses développeurs ont écrit son accessibilité | À vue |
| Une grille ou une liste dessinée par le propriétaire | Des lignes sans leurs cellules, ou des cellules derrière des noms génériques | À vue, cellule par cellule |
| Une suite de contrôles tierce | Cela dépend de l'éditeur : d'une description complète à un seul panneau | Par ce que dit l'application là où elle le dit, à vue là où elle ne le dit pas |
| Une image, une icône, un dessin | Une image sans texte | À vue |
La documentation de Microsoft elle-même dit qu'un contrôle sans fournisseur UI Automation lui est largement opaque, UI Automation ne pouvant guère signaler que son emplacement.Quelles applications Windows n'ont pas d'arbre d'accessibilité liste les types d'applications où c'est la règle plutôt que l'exception.
Les tests automatisés d'une application WPF : l'enregistrer étape par étape
Les tests automatisés d'une application WPF commencent par un enregistrement, dans GUI Test Runner-Recorder.Rien n'est ajouté à l'application : pas de build de test, pas de bibliothèque, pas d'AutomationId que vous n'aviez pas déjà.L'exemple ci-dessous enregistre une application de saisie de commandes, et une application WinForms s'enregistre de la même façon.Voir Enregistrer un test pour chaque option.
- 1
Cliquer sur Enregistrer
Ouvrez GUI Test Runner-Recorder et cliquez sur Enregistrer.Mettez votre application dans l'état d'où le test doit partir : le premier écran du parcours, sans rien d'autre d'ouvert dessus.
- 2
Répondre « Une application » à « Que voulez-vous tester ? »
Choisissez Une application et sélectionnez votre programme parmi ceux en cours d'exécution, ou parcourez jusqu'à son .exe s'il n'est pas encore ouvert.Cochez la case qui lance l'application avec le test et la ferme à la fin, pour que chaque exécution commence avec une application fraîche.
L'écran entier est toujours enregistré.Choisir Une application décide seulement d'où viennent les assertions automatiques. - 3
Utiliser l'application comme le ferait un testeur
Saisissez le nom du client, choisissez un produit dans la liste, cliquez sur Sauvegarder, et lisez la confirmation.Chaque clic et chaque touche sont enregistrés, et l'enregistreur découpe une image de chaque contrôle sur lequel vous cliquez, juste avant le clic.Appuyez sur la touche d'arrêt quand le parcours est terminé.
- 4
Répondre à « Que doit vérifier ce test ? »
Trois cartes demandent ce que le test doit vérifier : les éléments visuels sur lesquels vous avez cliqué, le texte à l'écran, et ce qui est apparu pendant que vous travailliez, comme une boîte de dialogue ou une confirmation.Gardez les valeurs par défaut pour un premier test, et sauvegardez.
Les assertions sont choisies après l'enregistrement, quand vous venez de voir ce que l'application a fait. - 5
Le test est sauvegardé dans un dossier qui lui est propre, et s'exécute
Un test nommé Orders est sauvegardé sous
Orders\Orders.GTS, dans un dossier qui lui est propre, où les résultats et l'historique de chaque exécution sont gardés à côté de lui.Cliquez sur Exécuter le test : le test rejoue vos clics et vos touches comme de vraies entrées, visant l'endroit où se trouve maintenant chaque contrôle, et se termine par un rapport de confiance qui dit ce qui a réussi et ce qui a changé.
Ce que l'enregistrement a gardé de chaque contrôle décide de la façon dont il est trouvé à l'exécution suivante.
- Pour le bouton Sauvegarder, l'application a dit Button, Save et SaveButton, et le test garde cela à côté de l'image du bouton.
- Pour le graphique, l'application n'a rien dit qui vaille la peine d'être gardé, et l'image seule le trouve.
Vous pouvez aussi vous passer de l'enregistrement et décrire le parcours dans une consigne à Claude, ChatGPT ou un modèle d'IA local, l'un des nôtres ou le vôtre : le test est créé de la même façon, avec les mêmes assertions.
Les tests d'interface WinForms : les assertions qui survivent à une refonte
Les tests d'interface WinForms, comme les tests WPF, tiennent ou tombent sur des assertions qui attrapent un vrai changement et ignorent les changements anodins.GUI Test Studio en propose trois types, chacun un bloc sur la chronologie du test que n'importe qui dans l'équipe peut ajouter, déplacer ou modifier.
Assertion visuelle
Une assertion visuelle vérifie qu'un élément est à l'écran et a l'apparence enregistrée : une icône de barre d'outils, un voyant d'état, un graphique qui doit montrer la même courbe.
Assertion de texte
Une assertion de texte vérifie les mots qu'affiche un élément, en interrogeant d'abord l'application et en lisant l'écran quand l'application ne peut pas le dire, et une assertion de texte dynamique accepte une valeur qui change selon son format, comme un numéro de commande.
Assertion de disposition
Une assertion de disposition vérifie que les éléments d'un écran sont agencés comme à l'enregistrement, si bien qu'une colonne qui a bougé ou un bouton qui a perdu sa place est attrapé même quand chaque élément a encore la bonne apparence.
Les trois ignorent le bruit que tout écran comporte et attrapent quand même ce qu'une personne appellerait un changement : une mauvaise couleur, une icône manquante, un mot qui a changé de casse, un contrôle qui a glissé de sa place.Assertions visuelles passe en revue les réglages de chacune.
La zone de recherche
Chaque assertion cherche son élément dans une zone de recherche, une zone autour de l'endroit où l'élément a été enregistré.La zone tient les sosies à distance : un bouton Sauvegarder dans la barre d'outils et un bouton Sauvegarder dans une boîte de dialogue se distinguent par l'endroit où chacun se trouve.Une assertion qui n'a pas trouvé son élément dans sa zone au bout d'une seconde cherche aussi sur tout l'écran, si bien qu'une fenêtre ouverte plus à droite ne fait pas échouer le test, et le rapport de confiance dit où l'élément a été trouvé.
Une refonte du code derrière un contrôle
Un test continue de fonctionner à travers les changements que traverse une application WPF ou WinForms.
- Un contrôle réécrit de WinForms en WPF est toujours trouvé : l'application le nomme toujours, et il a toujours la même apparence.
- Un contrôle déplacé dans un autre panneau est trouvé là où il se trouve maintenant.
- Une classe renommée ou une nouvelle bibliothèque de contrôles ne change rien de ce sur quoi le test s'appuie.
Un thème sombre, un thème à contraste élevé, une autre langue
Les informations d'accessibilité de l'application ne changent pas avec un thème, si bien qu'une assertion qui interroge l'application tient en clair comme en sombre.L'image que compare une assertion visuelle, elle, change, et un profil de référence garde une version attendue par environnement : exécutez le test avec le profil « Mode sombre », acceptez chaque nouvelle apparence une fois dans le rapport de confiance, et le même test vérifie ensuite l'apparence claire et l'apparence sombre, chacune par rapport à la bonne version.
Un localisateur casse quand le code change.Une assertion qui interroge l'application et regarde l'écran casse quand l'écran est faux, ce qui est le seul échec que vous voulez.
L'automatisation des tests d'applications de bureau Windows à chaque build
L'automatisation des tests d'applications de bureau Windows est rentable quand elle tourne sans que personne ne la lance. gtr-cli, l'exécuteur en ligne de commande, exécute un test exactement comme le bouton Exécuter le test et répond comme un pipeline l'attend : un test en échec fait échouer le build, un fichier JUnit remplit l'onglet des tests, et chaque image de ce qui a échoué est gardée dans un seul dossier.
gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifactsUne option nomme l'outil de CI, et les échecs apparaissent alors dans son propre journal, sous forme d'annotations ou d'entrées de test, sans plugin à installer :
| Outil de CI | La commande | Ce que l'outil affiche |
|---|---|---|
| TeamCity | gtr-cli run tests --countdown 0 --format teamcity --artifacts results\artifacts | Chaque test dans l'onglet Tests, les échecs avec leurs raisons |
| Azure DevOps | gtr-cli run tests --countdown 0 --format azure --junit results\junit.xml --artifacts results\artifacts | Une commande de journalisation par échec, et le fichier JUnit dans l'onglet Tests |
| GitHub Actions | gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts | Une annotation par échec sur l'exécution, et le dossier des artefacts à télécharger |
Un test d'application de bureau se rejoue sur un vrai écran, donc l'agent de build a besoin d'une session de bureau Windows déverrouillée : une machine virtuelle avec une taille d'écran fixe fonctionne bien.Exécuter des tests dans votre pipeline liste chaque option, et Exécutez vos tests de bout en bout à chaque build configure un build TeamCity étape par étape, avec la même commande pour Jenkins, GitHub Actions, GitLab et Azure DevOps.
FlaUI, pywinauto et les autres outils de test d'interface WPF : quand le code est le bon choix
Deux bibliothèques open source sont ce vers quoi un développeur se tournerait autrement.FlaUI est une bibliothèque .NET pour les tests d'interface automatisés d'applications Windows, WPF et WinForms comprises, qui enveloppe les bibliothèques UI Automation de Microsoft pour un test écrit en C#.pywinauto, sur sa page GitHub, est un ensemble de modules Python pour automatiser l'interface graphique de Windows, avec deux moteurs : l'API Win32, par défaut, et UI Automation.
Les deux sont un choix honnête pour une équipe orientée code dont tous les contrôles sont accessibles : les tests vivent dans le propre dépôt de l'application, dans un langage que l'équipe écrit tous les jours, à côté des tests unitaires, et un développeur qui connaît l'arbre des contrôles peut écrire un localisateur précis pour chaque élément.Le coût se paie en temps de développeur, pour chaque localisateur et pour chaque refonte qui en change un, et un élément que l'application ne décrit pas demande une autre voie d'accès.
Les deux ne sont pas ennemis.Une équipe avec une application WPF pleine de contrôles personnalisés garde souvent ses tests unitaires en code et enregistre ses tests de bout en bout, si bien que les personnes qui connaissent le mieux les parcours peuvent les maintenir, et les contrôles que l'application ne décrit pas sont testés aussi.
Points clés
- 1WPF et WinForms décrivent leurs contrôles standard, et ne disent rien d'un graphique, d'une jauge, d'une grille dessinée par le propriétaire ou de nombreux contrôles tiers.
- 2Un seul enregistrement teste les deux types : le GTS Engine + AI interroge d'abord l'application et trouve le contrôle à vue quand l'application ne dit rien.
- 3Choisissez des assertions qui survivent à une refonte : une assertion visuelle, une assertion de texte et une assertion de disposition n'échouent que quand l'écran est faux, et un profil de référence couvre un thème sombre.
- 4Exécutez-le à chaque build avec gtr-cli, dans TeamCity, Azure DevOps, GitHub Actions, Jenkins ou GitLab, sur un bureau Windows déverrouillé.
- 5FlaUI et pywinauto gardent leur intérêt pour une équipe orientée code dont tous les contrôles sont accessibles ; le coût est du temps de développeur pour chaque localisateur.
Questions
Comment automatiser les tests d'interface d'une application WPF ?
Enregistrez un parcours une fois dans GUI Test Studio : ouvrez l'application, cliquez, saisissez et lisez ce qui apparaît, comme le ferait un testeur.Chaque action et chaque assertion deviennent un test sans code, et gtr-cli l'exécute de nouveau à chaque build.Chaque contrôle est trouvé par les informations d'accessibilité de l'application, ou à vue quand l'application n'en dit rien.
Peut-on tester une application WinForms qui n'a pas d'AutomationId ?
Oui.Un contrôle WinForms standard indique toujours son type et son texte, et un contrôle qui n'indique rien d'utile est trouvé à vue, par son image à l'écran.Rien ne doit être ajouté à l'application pour que le test fonctionne.
Dois-je ajouter des AutomationId à mon application WPF pour automatiser les tests ?
Pas avec GUI Test Studio.Un AutomationId aide, parce que l'application nomme alors le contrôle précisément, et GUI Test Studio le garde quand il y en a un.Sans lui, le nom, le type et la place du contrôle, ainsi que son image, suffisent.
Comment tester des contrôles dessinés sur mesure ou tiers dans une application WPF ?
À vue.Un graphique, une jauge, une grille dessinée par le propriétaire ou un contrôle tiers ne montre souvent à Windows qu'un rectangle vide.GUI Test Studio trouve un tel contrôle par son image dans sa zone de recherche, agit dessus avec de vraies entrées de souris et de clavier, et vérifie ce qu'il affiche de la même façon.
Quelle alternative à FlaUI ne demande pas de code ?
GUI Test Studio.FlaUI est une bibliothèque .NET qui pilote Windows UI Automation depuis du code C#, si bien que chaque élément a besoin d'un localisateur dans un projet de test.GUI Test Studio enregistre plutôt le parcours, garde de lui-même les informations d'accessibilité de l'application, et trouve à vue ce que l'application ne décrit pas.
L'automatisation des tests WPF fonctionne-t-elle avec un thème sombre ?
Oui.Les informations d'accessibilité de l'application ne changent pas avec un thème, et pour les assertions qui comparent une image, un profil de référence garde une version attendue par thème.Le même test s'exécute sur l'apparence claire et sur l'apparence sombre, et compare chacune avec la bonne version.
Les tests WPF et WinForms peuvent-ils tourner dans un pipeline CI/CD ?
Oui. gtr-cli exécute les tests sur un agent de build Windows avec une session de bureau déverrouillée, fait échouer le build quand un test échoue, écrit un fichier JUnit et garde chaque image d'un échec.Il fonctionne avec TeamCity, Azure DevOps, GitHub Actions, Jenkins et GitLab.
Faut-il installer quoi que ce soit dans l'application ?
Non.GUI Test Studio regarde l'écran, demande à Windows ce que l'application décrit déjà d'elle-même, et utilise la souris et le clavier comme une personne.Il n'y a ni bibliothèque, ni build de test, ni agent dans l'application.
Microsoft, Windows, WPF, Windows Forms, FlaUI, pywinauto, TeamCity, Azure DevOps, GitHub, GitLab et Jenkins sont des marques ou des projets de leurs propriétaires respectifs.
Prêt à enregistrer votre premier test ?
Toutes les fonctionnalités, pendant 15 jours.
Vous préférez le voir sur le type d'application que vous testez ?Réservez un appel gratuit de 30 minutes avec notre équipe.